On 5/11/20 1:26 PM, Guilherme Piccoli wrote: > On Sun, May 10, 2020 at 10:25 PM David Rientjes <rientjes@xxxxxxxxxx> wrote: >> [...] >> The kernel log is not preferred for this (or drop_caches, really) because >> the amount of info can causing important information to be lost. We don't >> really gain anything by printing that someone manually triggered >> compaction; they could just write to the kernel log themselves if they >> really wanted to. The reverse is not true: we can't suppress your kernel >> message with this patch. >> >> Instead, a statsfs-like approach could be used to indicate when this has >> happened and there is no chance of losing events because it got scrolled >> off the kernel log. It has the added benefit of not requiring the entire >> log to be parsed for such events. > OK, agreed! Let's forget the kernel log. So, do you think the way to > go is the statsfs, not a zoneinfo stat, a per-node thing? I'm saying > that because kernel mm subsystem statistics seem pretty.."comfortable" > the way they are, in files like vmstat, zoneinfo, etc. Let me know > your thoughts on this, if I could work on that or should wait statsfs. > Thanks, > > > Guilherme I think a trace notification in compaction like kcompad_wake would be good.
