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
> > > > k
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
> > 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
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 t
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
> > > descendin
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 physical address.
> >
>
> OIC. -mm's /proc/pid/pagemap can be used to get
Mel Gorman wrote:
On (13/12/07 16:37), Andrew Morton didst pronounce:
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
On (13/12/07 16:37), Andrew Morton didst pronounce:
> 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(s
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,
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 *pa
Mark Lord wrote:
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
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 lin
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
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 hav
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 culpri
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 bvp
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
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 rein
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
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 fo
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
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
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, M
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, 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
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. 2.6.
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
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 suspici
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. 2.6.23.8 regularly generates segments up to
64KB for libata,
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
On Thu, Dec 13 2007, 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
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 segment
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 suspici
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 suspici
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 configs
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 / simi
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 d
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
> > byte
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).
>
(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 probl
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 la
42 matches
Mail list logo