Ok, so that all wasn't really good, sending IPIs about like that on
LargeSMP will not make me any friends, so how about this:
---
include/linux/backing-dev.h | 13 -
mm/backing-dev.c| 28 ++--
mm/page-writeback.c | 19 +++--
On Wed, 2007-04-04 at 14:32 +0200, Miklos Szeredi wrote:
> > Preferably you'd want to be able to 'flush' the per cpu diffs or
> > something like that in cases where thresh ~< NR_CPUS * stat_diff.
> >
> > How about something like this:
>
> Yes, maybe underscores and EXPORT_SYMBOLs are a bit excess
> Preferably you'd want to be able to 'flush' the per cpu diffs or
> something like that in cases where thresh ~< NR_CPUS * stat_diff.
>
> How about something like this:
Yes, maybe underscores and EXPORT_SYMBOLs are a bit excessive.
Miklos
-
To unsubscribe from this list: send the line "unsubscr
On Wed, 2007-04-04 at 13:12 +0200, Miklos Szeredi wrote:
> > > > so it could be that: scale / cycle > 1
> > > > by a very small amount; however:
> > >
> > > No, I'm worried about the case when scale is too small. If the
> > > per-bdi threshold becomes smaller than stat_threshold, then things
> >
> > > so it could be that: scale / cycle > 1
> > > by a very small amount; however:
> >
> > No, I'm worried about the case when scale is too small. If the
> > per-bdi threshold becomes smaller than stat_threshold, then things
> > won't work, because dirty+writeback will never go below the thresho
On Wed, 2007-04-04 at 12:29 +0200, Miklos Szeredi wrote:
> > > I'm worried about two things:
> > >
> > > 1) If the per-bdi threshold becomes smaller than the granularity of
> > >the per-bdi stat (due to the per-CPU counters), then things will
> > >break. Shouldn't there be some sanity che
> > I'm worried about two things:
> >
> > 1) If the per-bdi threshold becomes smaller than the granularity of
> >the per-bdi stat (due to the per-CPU counters), then things will
> >break. Shouldn't there be some sanity checking for the calculated
> >threshold?
>
> I'm not sure what y
On Wed, 2007-04-04 at 11:34 +0200, Miklos Szeredi wrote:
> > Scale writeback cache per backing device, proportional to its writeout
> > speed.
> >
> > akpm sayeth:
> > > Which problem are we trying to solve here? afaik our two uppermost
> > > problems are:
> > >
> > > a) Heavy write to queue A
> Scale writeback cache per backing device, proportional to its writeout speed.
>
> akpm sayeth:
> > Which problem are we trying to solve here? afaik our two uppermost
> > problems are:
> >
> > a) Heavy write to queue A causes light writer to queue B to blok for a long
> > time in balance_dirty_
9 matches
Mail list logo
