> And for this reason I think these cache trimming patches are dubious:
>
> 1) On a uniprocessor the memory consumption of the pte caches are
> not even on the radar.
Huh? On UP the cache size is the same, 25 pages at the low watermark,
and this can make a difference to fragmentation. Furthermore, the
preponderance of smaller memory machines are UP (does anyone have dual
processors with only 16M?), so the unavailable memory is likely to be
more important.
> 2) On an SMP system, you can only immediately trim the local cpu's
> pte cache.
Yes, this indicates that we need a mechanism to drain the other caches
as well.
> Note, I kept the cache trimming in the idler loop specifically because
> when the machine begins to get memory pressure (to the point where we
> would actually begin to care about pte cache consumption) there is
> always a quick thread of control into the idler task for at least one
> iteration while people block. I tested this, and this is why I am so
> against your cache trimming changes. Please show me evidence that the
> current heuristics are insufficient and do not work, I put a lot of
> time into it's design.
The idler loop may eventually get some time when everyone blocks for
swap-in, but this isn't synchronous with the attempts to reclaim and
defragment memory. The important point though is that the caches don't
get trimmed below 25 pages, even if the system is dying a death of
swapping.
For evidence that the pte caches are tying up memory, just press shift
scrolllock while the system is swapping. You'll often see 25 pages in
page table cache even under heavy swapping. With my patch in place the
value is usually 0 when swapping, 25-50 otherwise.
> Your misunderstanding of the per-cpu locking issues evidences that you
> did not study it's inner workings and heuristics very well, so as a
> result I'm quite leery of the changes you are making.
Right, I overlooked the macro definitions that made the lists look like
ordinary scalars. You get 3 points for a successful code obfuscation.
I hope the goal here isn't to bash me for misreading the need for
locking, but rather to get 2.1 working properly so that it can become
2.2. Solving the remaining memory issues, especially wrt fragmentation,
is a major part of this.
Regards,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html