On Tue, 2010-09-28 at 22:08 +0800, Christoph Lameter wrote:
> On Tue, 28 Sep 2010, Mel Gorman wrote:
>
> > On Tue, Sep 28, 2010 at 08:40:15AM -0500, Christoph Lameter wrote:
> > > On Tue, 28 Sep 2010, Mel Gorman wrote:
> > >
> > > > Which of these is better or is there an alternative suggestion on how
> > > > this livelock can be avoided?
> > >
> > > We need to run some experiments to see what is worse. Lets start by
> > > cutting both the stats threshold and the drift thing in half?
> > >
> >
> > Ok, I have no problem with that although again, I'm really not in the position
> > to roll patches for it right now. I don't want to get side-tracked.
>
> Ok the stat threshold determines the per_cpu_drift_mark.
>
> So changing the threshold should do the trick. Try this:
doesn't work here, perf still shows the same overhead.
in the system:
Node 3, zone Normal
pages free 2055926
min 1441
low 1801
high 2161
scanned 0
spanned 2097152
present 2068480
vm stats threshold: 98
(low-min)/NR_CPU = (1801-1441)/64 = 5
so when the threshold is 5, there is no per_cpu_drift_mark.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>