* Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
Here were some of my concerns, and where our discussion got up to.
Yes. Perhaps it just doesn't help with the updatedb thing. Or maybe with normal system activity we get enough free pages to kick the thing off and running. Perhaps updatedb itself has a lot of rss, for example.
Could be, but I don't know. I'd think it unlikely to allow _much_ swapin, if huge amounts of the desktop have been swapped out. But maybe... as I said, nobody seems to have a recipe for these things.
can i take this one as a "no fundamental objection"? There are really only 2 maintainance options left:
1) either you can do it better or at least have a _very_ clearly
described idea outlined about how to do it differently
2) or you should let others try it
#1 you've not done for 2-3 years since swap-prefetch was waiting for
integration so it's not an option at this stage anymore. Then you are pretty much obliged to do #2. ;-)
2) It is a _highly_ speculative operation, and in workloads where periods
of low and high page usage with genuinely unused anonymous / tmpfs
pages, it could waste power, memory bandwidth, bus bandwidth, disk
bandwidth...
Yes. I suspect that's a matter of waiting for the corner-case reporters to complain, then add more heuristics.
Ugh. Well it is a pretty fundamental problem. Basically swap-prefetch is happy to do a _lot_ of work for these things which we have already decided are least likely to be used again.
i see no real problem here. We've had heuristics for a _long_ time in various areas of the code. Sometimes they work, sometimes they suck.
4) If this is helpful, wouldn't it be equally important for things like
mapped file pages? Seems like half a solution.
[...]
(otoh the akpm usersapce implementation is swapoff -a;swapon -a)
Perhaps. You may need a few indicators to see whether the system is idle... but OTOH, we've already got a lot of indicators for memory, disk usage, etc. So, maybe :)
The time has passed for this. Let others play too. Please :-)
I could be wrong, but IIRC there is no good way to know which cpuset to bring the page back into, (and I guess similarly it would be hard to know what container to account it to, if doing account-on-allocate).
(i think cpusets are totally uninteresting in this context: nobody in their right mind is going to use swap-prefetch on a big NUMA box. Nor can i see any fundamental impediment to making this more cpuset-aware, just like other subsystems were made cpuset-aware, once the requests from actual users came in and people started getting interested in it.)
I think the "lack of testcase and numbers" is the only valid technical objection i've seen so far.