linux-kernel - Re: [PATCH] delayacct: track delays from ksm cow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Mar 2022 01:41:21 +0000
From:   CGEL <cgel.zte@...il.com>
To:     David Hildenbrand <david@...hat.com>
Cc:     bsingharora@...il.com, akpm@...ux-foundation.org,
        yang.yang29@....com.cn, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH] delayacct: track delays from ksm cow

On Thu, Mar 17, 2022 at 11:05:22AM +0100, David Hildenbrand wrote:
> On 17.03.22 10:48, CGEL wrote:
> > On Thu, Mar 17, 2022 at 09:17:13AM +0100, David Hildenbrand wrote:
> >> On 17.03.22 03:03, CGEL wrote:
> >>> On Wed, Mar 16, 2022 at 03:56:23PM +0100, David Hildenbrand wrote:
> >>>> On 16.03.22 14:34, cgel.zte@...il.com wrote:
> >>>>> From: Yang Yang <yang.yang29@....com.cn>
> >>>>>
> >>>>> Delay accounting does not track the delay of ksm cow.  When tasks
> >>>>> have many ksm pages, it may spend a amount of time waiting for ksm
> >>>>> cow.
> >>>>>
> >>>>> To get the impact of tasks in ksm cow, measure the delay when ksm
> >>>>> cow happens. This could help users to decide whether to user ksm
> >>>>> or not.
> >>>>>
> >>>>> Also update tools/accounting/getdelays.c:
> >>>>>
> >>>>>     / # ./getdelays -dl -p 231
> >>>>>     print delayacct stats ON
> >>>>>     listen forever
> >>>>>     PID     231
> >>>>>
> >>>>>     CPU             count     real total  virtual total    delay total  delay average
> >>>>>                      6247     1859000000     2154070021     1674255063          0.268ms
> >>>>>     IO              count    delay total  delay average
> >>>>>                         0              0              0ms
> >>>>>     SWAP            count    delay total  delay average
> >>>>>                         0              0              0ms
> >>>>>     RECLAIM         count    delay total  delay average
> >>>>>                         0              0              0ms
> >>>>>     THRASHING       count    delay total  delay average
> >>>>>                         0              0              0ms
> >>>>>     KSM             count    delay total  delay average
> >>>>>                      3635      271567604              0ms
> >>>>>
> >>>>
> >>>> TBH I'm not sure how particularly helpful this is and if we want this.
> >>>>
> >>> Thanks for replying.
> >>>
> >>> Users may use ksm by calling madvise(, , MADV_MERGEABLE) when they want
> >>> save memory, it's a tradeoff by suffering delay on ksm cow. Users can
> >>> get to know how much memory ksm saved by reading
> >>> /sys/kernel/mm/ksm/pages_sharing, but they don't know what the costs of
> >>> ksm cow delay, and this is important of some delay sensitive tasks. If
> >>> users know both saved memory and ksm cow delay, they could better use
> >>> madvise(, , MADV_MERGEABLE).
> >>
> >> But that happens after the effects, no?
> >>
> >> IOW a user already called madvise(, , MADV_MERGEABLE) and then gets the
> >> results.
> >>
> > Image user are developing or porting their applications on experiment
> > machine, they could takes those benchmark as feedback to adjust whether
> > to use madvise(, , MADV_MERGEABLE) or it's range.
> 
> And why can't they run it with and without and observe performance using
> existing metrics (or even application-specific metrics?)?
> 
>
I think the reason why we need this patch, is just like why we need                                                                                                     
swap,reclaim,thrashing getdelay information. When system is complex,
it's hard to precise tell which kernel activity impact the observe
performance or application-specific metrics, preempt? cgroup throttle?
swap? reclaim? IO?

So if we could get the factor's precise impact data, when we are tunning
the factor(for this patch it's ksm), it's more efficient.

> -- 
> Thanks,
> 
> David / dhildenb