I don't mean to divert the thread too much. But just one suggestion
offered by Harshad.
Why can't we stop invoking more of a KSM scanner thread when we are
saturating from savings ? But again, to check whether savings are
saturated or not, we may still want to rely upon timers and we have to
wake the CPUs up from IDLE state.
here. Can't we create a new (timer) infrastructure that does the right
thing? Surely this isn't the only such case.
A sleep-walking timer, that goes to sleep in one bed, but may wake in
another; and defers while beds are empty? I'd be happy to try using
that for KSM if it already existed, and no doubt Chintan would too
This is interesting for sure :)
But I don't think KSM presents a very good case for developing it.
I think KSM's use of a sleep_millisecs timer is really just an apology
for the amount of often wasted work that it does, and dates from before
we niced it down 5. I prefer the idea of a KSM which waits on activity
amongst the restricted set of tasks it is tracking: as this patch tries.
But my preference may be naive: doing lots of unnecessary work doesn't
matter as much as waking cpus from deep sleep.
This is exactly the preference we are looking for. But yes, cannot be
generalized for all.
I know both RCU and some NOHZ_FULL muck already track when the system is
completely idle. This is yet another case of that.
Hugh
--
Chintan Pandya
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>