Messages in this thread | | | Subject | Re: [PATCH] pagemap: early return on unmapped areas | From | Matt Mackall <> | Date | Thu, 14 Jan 2010 11:02:11 -0600 |
| |
On Thu, 2010-01-14 at 16:52 +0800, Wu Fengguang wrote: > On Thu, Jan 14, 2010 at 04:30:48PM +0800, Andi Kleen wrote: > > > --- > > > pagemap: early return on unmapped areas > > > > Yes seems like a reasonable idea. > > Thanks! > > I just changed the ">" to ">=", because it happen to make a difference > for cp/cat, which does 4k sized read: > > 4k read buffer = 4k/8 pages = 512 pages = NR_PMD_PAGES > > So the change to ">=" makes cp exit immediately (4k buffer matches > exactly one PMD hole). > > before > dd if=/proc/$$/pagemap of=/dev/null bs=4k > 512+0 records in > 512+0 records out > 2097152 bytes (2.1 MB) copied, 0.0225796 s, 92.9 MB/s > > after > dd if=/proc/$$/pagemap of=/dev/null bs=4k > 0+0 records in > 0+0 records out > 0 bytes (0 B) copied, 2.8029e-05 s, 0.0 kB/s
Have you guys lost your minds?
I regularly used the exact standard tool you just broke above to test pagemap when I was developing it. There's no doubt that this patch (or any similarly misguided ones) WILL regress existing naive or not intended to be portable 32-bit users. And if I was some poor future bastard trying to write a program against pagemap with your patch, odds of getting a concussion banging my head against the wall trying to figure out its highly non-file-like behavior would be quite high.
Why are we even still on this. There's no regression. LTP + pagemap + 64-bit has always behaved thus. Nor are large virtual files new. And LTP's n00b assumption that it can just read all of any file in /proc has always been wrong. LTP had the exact same problem on 64-bit /proc/kcore (how long has that existed?) and finally fixed it in 2005.
-- http://selenic.com : development and support for Mercurial and Linux
| |