I think I found out what's up here. readpage() will read from the
buffer cache if the data is already cached (i.e. a previous write
operation put it there). In the 2.2.16 case, since I write to my own
LRU, then indirect reads through generic_read_file(), generic_readpage()
will always assume that the PageUptodate is cleared which always forces
readpage() to re-read the page -- this creates the affect of a write
through page cache -- clearly not what we want here. I guess the
solution here is to either scrap the NWFS LRU completely for the 2.2.16
page cache, or implement my own readpage() for 2.2.16 so page cache
reads hit my LRU instead of the buffer cache.
Tried my own readpage() (cut and pasted from the 2.4 version of NWFS) -
22,000,000 bytes/second through the NWFS LRU with my own readpage() -- I
think I found the problem...
:-)
Jeff
"Jeff V. Merkey" wrote:
>
> I am going back now and fixing a few bugs, namely MKISOFS and IOZONE for
> NWFS. I've also added calls to generic_file_read, bmap, and readpage
> for 2.2.16 as well as 2.4 and 2.0.38. MKISOFS turned out to be a
> GLIB/POSIX bug in the way that MKISOFS interacts while using readdir()
> -- it still has some problems with NCPFS, SMBFS, etc. but NWFS works
> now. At any rate, the obvious solution for me here is to create a
> "virtual" directory file for each directory in my directory asssign
> hash, which was needed anyway to complete the salvageable file system,
> so this turned out to be a very useful exercise. But on to the main
> point.
>
> While fixing the deadlocks in IOZONE (thanks to Al Viro, this is now
> fixed -- removing the locks from create.c really sped things up and got
> rid of most of the deadlocks that were remaining), I noticed **DISMALL**
> read performance running IOZONE after I converted from the NWFS LRU to
> Linus' Page Cache interface in 2.2.16 with generic_read_file(),
> readpage(), etc. so that NWFS can support fully memory mapped files
> (Andi Klein -- this one's for you). Performance for writes to a file is
> on par with EXT2 and EXT3, however, reads really suck wind with this
> test with NWFS if I use generic_read_file(). EXT2 is getting @
> 24,000,000 bytes/second while NWFS is only getting 4,000,000
> bytes/second running the same test through the page cache. Writes
> perform identically to EXT2 (2,000,000 bytes/second) which would
> indicate I am hitting I/O limits for the box (dual processor PPro 200
> Mhz System).
>
> Is there a penalty for being deviceless vs. device file systems on the
> VFS? It looks like I am hitting an artificial barrier. When I use the
> NWFS LRU for reads, I get 26,000,000 bytes/second as opposed to
> 4,000,000 bytes/second compared with the 2.2.16 page cache with
> generic_read_file(). I would rather use Linus's page cache since if I
> do, all the mmap user space stuff works correctly. I also noticed that
> smap() exists in the fat FS's but nowhere else. I am assuming I don't
> need smap() for mmap support.
>
> Please advise.
>
> :-)
>
> Jeff
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:26 EST