Re: 2.6.4-rc1-mm1

[Nick Piggin]

Andrew Morton wrote:

> Nick Piggin <piggin@xxxxxxxxxxxxxxx> wrote:
>
> > I had one addition which is to use a "refill_counter" for inactive
> > list scanning as well so the scanning is batched up now that we don't
> > round up the amount to be done. No observed benefits, but I imagine
> > it would lower the acquisition frequency of the lru locks in some
> > cases?
>
> Might do, yes.

OK I've sent you a patch to do that.

> Also I think you did some work on the inactive-vs-active list balancing?  I
> have spent precisely zero time looking at or working on that since
> 2.5.nothing and it's entirely possible that it is doing something
> inappropriate.

Yes I did. I will continue to look into this.

> > Should I start testing again, or are you still doing more to vmscan?
>
> Now would be a good time.  The only thing I'm likely to look at in the next
> several days is accounting for the slab fragmentation.  My current thinking
> is to solve that by making slab account for the number of objects and the
> number of pages, and to use that in shrink_dcache_memory(), so it doesn't
> touch vmscan.c at all.

My thinking is to go by number of pages. Then you get to tell the
shrinker: we scanned this many pages of LRU, so please scan an
equivalent percentage of slab *pages*.

You can then translate this to number of slab objects before scanning.

Oh, apart from that, there is still one thing that I'm not sure is
correct about slab scanning... we scan slab in response to scanning
a part of the inactive list, but we apply this pressure as if it
were a ratio of active + inactive lists.

This will cause slab to be scanned less, but my main worry is that
it makes slab scanning behaviour dependant on the ratio of active to
inactive list size: the bigger your active list, the less slab will
be scanned which I think is silly. But I might be wrong.

> > Nikita's dont-rotate-active-list.patch looks to be the only major
> > casualty. I found this patch pretty important, so I will definitely
> > like to demonstrate its benefits. One question remains, would you
> > accept the patch in its current form?
>
> We should bring that back for testing, please.  I need to sit down and
> think a bit more about test suites which replicate workloads which we care
> about before making any decisions.
>
> One point I would make is that if a workload is only achieving 5% CPU
> anyway, we shouldn't optimise for it.  Sure, it's nice to be able to get it
> up to 7% but it is much more important to get the 50% CPU workload up to
> 70%.  The 5% problem is a fiscal one, not an engineering one ;)

I agree. I'm much more interested in getting light and medium swapping
working better.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/