On Mon, May 18, 2020 at 9:54 AM Enderborg, Peter
wrote:
> Usually change existing causes confusion. It should not be a problem but it
> happen.
>
I am sorry, but I really didn't understand your statement, can you be
more specific?
Thanks again!
On 5/18/20 2:14 PM, Guilherme Piccoli wrote:
> Hi Peter, thanks for the feedback. What do you mean by "trace
> notification" ? We seem to have a trace event in that function you
> mentioned. Also, accounting for that function is enough to
> differentiate when the compaction is triggered by the
Hi Peter, thanks for the feedback. What do you mean by "trace
notification" ? We seem to have a trace event in that function you
mentioned. Also, accounting for that function is enough to
differentiate when the compaction is triggered by the kernel itself or
by the user (which is our use case
On 5/11/20 1:26 PM, Guilherme Piccoli wrote:
> On Sun, May 10, 2020 at 10:25 PM David Rientjes 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
On Sun, May 10, 2020 at 10:25 PM David Rientjes 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;
On Fri, 8 May 2020, Guilherme Piccoli wrote:
> On Fri, May 8, 2020 at 3:31 PM David Rientjes wrote:
> > It doesn't make sense because it's only being done here for the entire
> > system, there are also per-node sysfs triggers so you could do something
> > like iterate over the nodemask of all
On Fri, May 8, 2020 at 3:31 PM David Rientjes wrote:
> It doesn't make sense because it's only being done here for the entire
> system, there are also per-node sysfs triggers so you could do something
> like iterate over the nodemask of all nodes with memory and trigger
> compaction manually and
On Thu, 7 May 2020, Guilherme G. Piccoli wrote:
> Well...you can think that the problem we are trying to solve was more
> like...admin forgot if they triggered or not the compaction hehe
> So, counting on the user to keep track of it is what I'd like to
> avoid. And thinking about drop_caches
On Thu, May 7, 2020 at 8:04 PM Andrew Morton wrote:
>
> Could add it to vmstat?
Hi Andrew, thanks for your suggestion! I thought the same, as a second
potential solution for this..was planning to add as a comment below
the "---" but forgot heheh
I agree that would be great in vmstat, do you have
On Thu, 7 May 2020 18:59:46 -0300 "Guilherme G. Piccoli"
wrote:
> Currently we have no way to determine if compaction was triggered
> by sysctl write, but this is an interesting information to have,
> specially in systems with high uptime that presents lots of
> fragmented memory. There's no
Currently we have no way to determine if compaction was triggered
by sysctl write, but this is an interesting information to have,
specially in systems with high uptime that presents lots of
fragmented memory. There's no statistic indicating if compaction
was triggered manually or ran by Linux
11 matches
Mail list logo
