On Sun, 16 Dec 2007 21:55:20 + 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
On Mon, Dec 17, 2007 at 11:24:57AM -0800, Randy Dunlap wrote:
On Sun, 16 Dec 2007 21:55:20 + 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
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
On Sat, 15 Dec 2007 01:09:41 + Mel Gorman [EMAIL PROTECTED] wrote:
On (13/12/07 14:29), Andrew Morton didst pronounce:
The simple way seems to be to malloc a large area, touch every page and
then look at the physical pages assigned ... they now mostly seem to be
descending in
On Fri, Dec 14, 2007 at 06:02:06PM -0800, Andrew Morton wrote:
On Sat, 15 Dec 2007 01:09:41 + Mel Gorman [EMAIL PROTECTED] wrote:
On (13/12/07 14:29), Andrew Morton didst pronounce:
The simple way seems to be to malloc a large area, touch every page and
then look at the physical
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 128 by default.
The problem is, the block layer *never* sends an SG entry
(resending with corrected email address for Jens)
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 128 by default.
The
On Thu, Dec 13, 2007 at 01:37:59PM -0500, Mark Lord wrote:
The problem is, the block layer *never* sends an SG entry larger than 8192
bytes,
and even that size is exceptionally rare. Nearly all I/O segments are 4096
bytes,
so I never see a single I/O larger than 512KB (128 * 4096).
If I
On Thu, 2007-12-13 at 11:42 -0700, Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:37:59PM -0500, Mark Lord wrote:
The problem is, the block layer *never* sends an SG entry larger than 8192
bytes,
and even that size is exceptionally rare. Nearly all I/O segments are 4096
bytes,
so
Mark Lord wrote:
(resending with corrected email address for Jens)
Jens,
I'm experimenting here with trying to generate large I/O through libata,
and not having much luck.
The limit seems to be the number of hardware PRD (SG) entries permitted
by the driver (libata:ata_piix), which is 128 by
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a suspicion ... could this be slab vs slub? ie check your configs
are the same /
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a suspicion ... could this be slab vs slub? ie check your
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a suspicion ... could
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to 64KB for
libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB segments.
Just a
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to
64KB for libata,
but 2.6.24 uses only 4KB segments and a *few* 8KB
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed. 2.6.23.8 regularly generates segments up to
64KB for libata,
but 2.6.24 uses
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord wrote:
Problem confirmed.
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500, Mark Lord
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500,
Jens Axboe wrote:
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On Thu, Dec 13, 2007 at 01:48:18PM -0500,
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew Wilcox wrote:
On
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Matthew
Mark Lord wrote:
Jens Axboe wrote:
..
OK, it's a vm issue, I have tens of thousand backward pages after a
boot - IOW, bvec-bv_page is the page before bvprv-bv_page, not
reverse. So it looks like that bug got reintroduced.
...
Mmm.. shouldn't one of the front- or back- merge logics work for
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Jens Axboe wrote:
On Thu, Dec 13 2007, Mark Lord wrote:
Mark Lord wrote:
Jens Axboe wrote:
On Thu,
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
OK, it's a vm issue,
cc linux-mm and probable culprit.
I have tens of thousand backward pages after a
boot - IOW, bvec-bv_page is the page before bvprv-bv_page, not
reverse. So it looks like that bug got reintroduced.
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
OK, it's a vm issue,
cc linux-mm and probable culprit.
I have tens of thousand backward pages after a
boot - IOW, bvec-bv_page is the page before
On Thu, Dec 13 2007, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
OK, it's a vm issue,
cc linux-mm and probable culprit.
I have tens of thousand backward pages after a
boot - IOW, bvec-bv_page is the page before bvprv-bv_page, not
Andrew Morton wrote:
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
OK, it's a vm issue,
cc linux-mm and probable culprit.
I have
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
OK, it's a vm issue,
cc linux-mm and probable culprit.
I have tens
Mark Lord wrote:
Andrew Morton wrote:
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
OK, it's a vm issue,
cc linux-mm and probable
Mark Lord wrote:
Mark Lord wrote:
Andrew Morton wrote:
On Thu, 13 Dec 2007 17:15:06 -0500
James Bottomley [EMAIL PROTECTED] wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:
On Thu, 13 Dec 2007 21:09:59 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
OK, it's a vm issue,
cc
Andrew Morton wrote:
On Thu, 13 Dec 2007 19:30:00 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Here's the commit that causes the regression:
...
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
order,
struct
On Thu, 13 Dec 2007 19:30:00 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Here's the commit that causes the regression:
...
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int
order,
struct page *page =
Mark Lord wrote:
Andrew Morton wrote:
On Thu, 13 Dec 2007 19:30:00 -0500
Mark Lord [EMAIL PROTECTED] wrote:
Here's the commit that causes the regression:
...
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone,
unsigned int order,
34 matches
Mail list logo
