From: Alain Knaff <Alain.Knaff@hitchhiker.org.lu>
To: Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Richard Gooch <rgooch@ras.ucalgary.ca>,
linux-kernel@vger.kernel.org
Subject: Re: Poor floppy performance in kernel 2.4.10
Date: Sat, 27 Oct 2001 21:13:56 +0200 [thread overview]
Message-ID: <200110271913.f9RJDup01632@hitchhiker.org.lu> (raw)
In-Reply-To: Your message of "Sat, 27 Oct 2001 13:42:32 EDT." <Pine.GSO.4.21.0110271320540.21545-100000@weyl.math.psu.edu>
>> All this begs of course the following question: what kind of
>> idnetifier does the buffer cache code actually use to refer to the
>> block device, if there is no longer a major?
>
>Right now - major:minor, in 2.5 - struct block_device *.
Actually, are you sure about that?
In filemap.c in do_generic_file_read, you have this:
struct address_space *mapping = filp->f_dentry->d_inode->i_mapping;
...
/*
* Try to find the data in the page cache..
*/
hash = page_hash(mapping, index);
spin_lock(&pagecache_lock);
page = __find_page_nolock(mapping, index, *hash);
Looks as if pages are identified by (mapping, index) pairs, rather
than (major:minor, index) triplets.
And "mapping" itself seems to point to i_data of the device's inode
structure (not the device entry's inode, but the device's itself).
Which means that if the inode is put (all references to the block
device closed), and later the same major/minor is reopened, it may
very well be in a different place in memory... Meaning that the
formerly cached pages (if they are still there...) will no longer be
recognized as the same, as mapping is now a different address, even
though major/minor is the same.
The changing nature of mapping can be confirmed easily by inserting a
printk into the open routine of the device.
As long as at least one reference to the device is open, mapping stays
the same for further opens, but as soon as the last ref is closed, the
next open will return a different address...
For the following test, I've inserted the following debugging printk
in floppy_open:
printk("Mapping=%x data=%x\n", inode->i_mapping, &inode->i_data);
As you see, while the sleep is open, Mapping is always
c25a7a90. However, once the sleep is closed, Mapping changes to
c1ba0cd0 . This seems to explain it things.
> sleep 3600 </dev/fd0 &
[1] 1449
Mapping=c25a7a90 data=cb80dc50
VFS: Disk change detected on device fd(2,0)
> mdir a:
Mapping=c25a7a90 data=cb80dc50
Volume in drive A has no label
Volume Serial Number is 63F7-FED8
Directory for A:/
No files
1 457 664 bytes free
> mdir a:
Mapping=c25a7a90 data=cb80dc50
Volume in drive A has no label
Volume Serial Number is 63F7-FED8
Directory for A:/
No files
1 457 664 bytes free
> kill %1
[1] + 1449 terminated sleep 3600 < /dev/fd0
> mdir a:
Mapping=c1ba0cd0 data=cb80dc50
Volume in drive A has no label
Volume Serial Number is 63F7-FED8
Directory for A:/
No files
1 457 664 bytes free
Regards,
Alain
next prev parent reply other threads:[~2001-10-27 19:13 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-27 15:00 Alain Knaff
2001-10-27 15:15 ` Alexander Viro
2001-10-27 17:12 ` Alain Knaff
2001-10-27 17:42 ` Alexander Viro
2001-10-27 18:00 ` Alain Knaff
2001-10-27 18:13 ` Alexander Viro
2001-10-27 18:26 ` Alexander Viro
2001-10-27 19:02 ` more devfs fun Alexander Viro
2001-10-27 19:16 ` Alexander Viro
2001-10-27 19:50 ` more devfs fun (Piled Higher and Deeper) Alexander Viro
2001-10-27 20:06 ` Alexander Viro
2001-10-27 21:09 ` Ryan Cumming
2001-10-27 21:22 ` Alexander Viro
2001-10-28 1:00 ` Rik van Riel
2001-10-28 8:45 ` Richard Gooch
2001-10-28 9:54 ` Alexander Viro
2001-10-28 12:27 ` Roman Zippel
2001-10-28 13:16 ` Alexander Viro
2001-10-28 22:31 ` Richard Gooch
2001-10-28 23:11 ` Alexander Viro
2001-10-27 21:01 ` Alexander Viro
2001-11-06 6:35 ` Richard Gooch
2001-11-06 7:10 ` Alexander Viro
2001-11-06 7:14 ` Richard Gooch
2001-11-06 7:17 ` Alexander Viro
2001-11-06 20:14 ` Richard Gooch
2001-10-28 10:06 ` Lorenzo Allegrucci
2001-11-06 5:21 ` Richard Gooch
2001-11-06 5:17 ` more devfs fun Richard Gooch
2001-11-06 5:06 ` Richard Gooch
2001-11-06 7:01 ` Poor floppy performance in kernel 2.4.10 Richard Gooch
2001-11-06 7:03 ` Alexander Viro
2001-12-09 5:38 ` Devfs races with block devices Richard Gooch
2001-11-06 7:19 ` Poor floppy performance in kernel 2.4.10 Richard Gooch
2001-11-06 7:22 ` Alexander Viro
2001-10-27 19:13 ` Alain Knaff [this message]
2001-10-27 19:19 ` Alexander Viro
2001-10-27 19:26 ` Alain Knaff
2001-10-28 20:40 ` Alain Knaff
2001-10-28 20:57 ` Peter T. Breuer
2001-10-29 5:38 ` Alain Knaff
2001-10-29 6:07 ` Alexander Viro
2001-10-29 6:34 ` Alain Knaff
2001-10-28 21:42 ` Alexander Viro
-- strict thread matches above, loose matches on Subject: below --
2001-10-21 11:36 Alain Knaff
2001-10-22 9:59 ` Andrea Arcangeli
2001-10-22 10:06 ` Alexander Viro
2001-10-22 14:07 ` Nick LeRoy
2001-10-22 18:28 ` bill davidsen
2001-10-19 16:58 Manfred Spraul
2001-10-17 7:36 Kamil Iskra
2001-10-17 20:45 ` Steve Kieu
2001-10-18 10:11 ` Kamil Iskra
2001-10-18 15:28 ` Andreas Dilger
2001-10-18 15:42 ` Kamil Iskra
2001-10-18 16:17 ` Ville Herva
2001-10-18 16:30 ` Nick LeRoy
2001-10-18 19:57 ` bill davidsen
2001-10-18 20:47 ` Nick LeRoy
2001-10-18 20:05 ` bill davidsen
2001-10-18 20:15 ` Alexander Viro
2001-10-18 16:18 ` Alexander Viro
2001-10-18 17:44 ` Andrea Arcangeli
2001-10-19 7:50 ` Giuliano Pochini
2001-10-19 13:46 ` Andrea Arcangeli
2001-10-19 15:57 ` Linus Torvalds
2001-10-20 4:20 ` Rob Landley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200110271913.f9RJDup01632@hitchhiker.org.lu \
--to=alain.knaff@hitchhiker.org.lu \
--cc=alain@linux.lu \
--cc=linux-kernel@vger.kernel.org \
--cc=rgooch@ras.ucalgary.ca \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®