linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Mel Gorman <mel@csn.ul.ie>,
	Andrew Morton <akpm@linux-foundation.org>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	jens.axboe@oracle.com, liml@rtr.ca, lkml@rtr.ca, matthew@wil.cx,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
Date: Mon, 17 Dec 2007 20:42:04 -0600	[thread overview]
Message-ID: <20071218024204.GR19691@waste.org> (raw)
In-Reply-To: <20071217112457.d7940c63.randy.dunlap@oracle.com>

On Mon, Dec 17, 2007 at 11:24:57AM -0800, Randy Dunlap wrote:
> On Sun, 16 Dec 2007 21:55:20 +0000 Mel Gorman wrote:
> 
> > > > Just using cp to read the file is enough to cause problems but I included
> > > > a very basic program below that produces the BUG_ON checks. Is this a known
> > > > issue or am I using the interface incorrectly?
> > > 
> > > I'd say you're using it correctly but you've found a hitherto unknown bug. 
> > > On i386 highmem machines with CONFIG_HIGHPTE (at least) pte_offset_map()
> > > takes kmap_atomic(), so pagemap_pte_range() can't do copy_to_user() as it
> > > presently does.
> > > 
> > > Drat.
> > > 
> > > Still, that shouldn't really disrupt the testing which you're doing.  You
> > > could disable CONFIG_HIGHPTE to shut it up.
> > > 
> > 
> > Yes, that did the trick. Using pagemap, it was trivial to show that the
> > 2.6.24-rc5-mm1 kernel was placing pages in reverse physical order like
> > the following output shows
> > 
> > b:  32763 v:   753091 p:    65559 . 65558 contig: 1
> > b:  32764 v:   753092 p:    65558 . 65557 contig: 1
> > b:  32765 v:   753093 p:    65557 . 65556 contig: 1
> > b:  32766 v:   753094 p:    65556 . 65555 contig: 1
> > b:  32767 v:   753095 p:    65555 . 65555 contig: 1
> > 
> > p: is the PFN of the page v: is the page offset within an anonymous
> > mapping and b: is the number of non-contiguous blocks in the anonymous
> > mapping. With the patch applied, it looks more like;
> > 
> > b:   1232 v:   752964 p:    58944 ................ 87328 contig: 15
> > b:   1233 v:   752980 p:    87328 ................ 91200 contig: 15
> > b:   1234 v:   752996 p:    91200 ................ 40272 contig: 15
> > b:   1235 v:   753012 p:    40272 ................ 85664 contig: 15
> > b:   1236 v:   753028 p:    85664 ................ 87312 contig: 15
> > 
> > so mappings are using contiguous pages again. This was the final test
> > program I used in case it's of any interest.
> > 
> > Thanks
> > 
> > /*
> >  * showcontiguous.c
> >  *
> >  * Use the /proc/pid/pagemap interface to give an indication of how contiguous
> >  * physical memory is in an anonymous virtual memory mapping
> >  */
> 
> Matt,
> Did you ever make your python pagemap scripts available?
> If not, would you?

There's a collection of them at http://selenic.com/repo/pagemap.
They're largely proof of concept, and I'm not sure I finished adapting
them all to the final 64-bit interface.

As it happens, the above regression I actually spotted immediately by
doing a simple hexdump on my very first test of the interface - lots
of pfns counting backwards. Mentioned it a few times to various people
in the cc: list and on lkml but never got around to tracking it down
myself..

-- 
Mathematics is the supreme nostalgia of our time.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-12-18  2:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20071213185326.GQ26334@parisc-linux.org>
     [not found] ` <4761821F.3050602@rtr.ca>
     [not found]   ` <20071213192633.GD10104@kernel.dk>
     [not found]     ` <4761883A.7050908@rtr.ca>
     [not found]       ` <476188C4.9030802@rtr.ca>
     [not found]         ` <20071213193937.GG10104@kernel.dk>
     [not found]           ` <47618B0B.8020203@rtr.ca>
     [not found]             ` <20071213195350.GH10104@kernel.dk>
     [not found]               ` <20071213200219.GI10104@kernel.dk>
     [not found]                 ` <476190BE.9010405@rtr.ca>
     [not found]                   ` <20071213200958.GK10104@kernel.dk>
2007-12-13 22:02                     ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Andrew Morton
2007-12-13 22:15                       ` James Bottomley
2007-12-13 22:29                         ` Andrew Morton
2007-12-13 22:33                           ` Mark Lord
2007-12-13 23:13                             ` Mark Lord
2007-12-14  0:05                               ` Mark Lord
2007-12-14  0:30                                 ` Mark Lord
2007-12-14  0:37                                   ` Andrew Morton
2007-12-14  0:42                                     ` Mark Lord
2007-12-14  0:46                                       ` [PATCH] fix page_alloc for larger I/O segments (improved) Mark Lord
2007-12-14  0:57                                         ` James Bottomley
2007-12-14  1:11                                           ` Andrew Morton
2007-12-14  2:23                                             ` Mark Lord
2007-12-14 17:42                                         ` Mel Gorman
2007-12-14 18:07                                           ` Mark Lord
2007-12-16 21:56                                             ` Mel Gorman
2007-12-14 18:13                                           ` Matthew Wilcox
2007-12-14 18:30                                             ` Mark Lord
2007-12-20 22:37                                             ` Matthew Wilcox
2007-12-14  0:47                                       ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Mark Lord
2007-12-14 11:50                                     ` Mel Gorman
2007-12-14 13:57                                       ` Mark Lord
2007-12-14  0:40                                   ` [PATCH] fix page_alloc for larger I/O segments Mark Lord
2007-12-14  1:03                                     ` Andrew Morton
2007-12-14  4:00                                       ` Matthew Wilcox
2007-12-15  1:09                           ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Mel Gorman
2007-12-15  2:02                             ` Andrew Morton
2007-12-15  5:55                               ` Matt Mackall
2007-12-16 21:55                               ` Mel Gorman
2007-12-17 19:24                                 ` Randy Dunlap
2007-12-18  2:42                                   ` Matt Mackall [this message]
2007-12-13 22:17                       ` Jens Axboe
2007-12-13 22:02                     ` VM allocates pages in reverse order again Matthew Wilcox

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=20071218024204.GR19691@waste.org \
    --to=mpm@selenic.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=jens.axboe@oracle.com \
    --cc=liml@rtr.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=matthew@wil.cx \
    --cc=mel@csn.ul.ie \
    --cc=randy.dunlap@oracle.com \
    /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;
as well as URLs for NNTP newsgroup(s).