linux-kernel - Re: [PATCH 2/3] delayacct: convert task->delays to a object

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]

Message-ID: <20231009141704.GE14330@noisy.programming.kicks-ass.net>
Date:   Mon, 9 Oct 2023 16:17:04 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     brookxu <brookxu.cn@...il.com>
Cc:     bsingharora@...il.com, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] delayacct: convert task->delays to a object

On Mon, Oct 09, 2023 at 06:29:15PM +0800, brookxu wrote:
> 
> 在 2023/10/9 16:43, Peter Zijlstra 写道:
> > On Sun, Oct 08, 2023 at 07:10:01PM +0800, brookxu wrote:
> > 
> > > > > @@ -1331,7 +1332,7 @@ struct task_struct {
> > > > >    	struct page_frag		task_frag;
> > > > >    #ifdef CONFIG_TASK_DELAY_ACCT
> > > > > -	struct task_delay_info		*delays;
> > > > > +	struct task_delay_info		delays;
> > > > >    #endif
> > > > Yeah, no.
> > > Yes, this way will increase about 80 bytes for task_struct, about 0.85% of
> > > size of task_struct, I think this just like sched_statistics, so that can
> > > better support dynamically enable through sysctl.
> > But it's 80 bytes 'nobody' will use. And arguably we should do the same
> > with schedstats, that's default disabled and again, that's per-task
> > storage nobody ever uses.
> > 
> > Per this argument we can grow task_struct indefinitely until it
> > collapses in on itself by the sheer weight of it's information density.
> > Every additional field will be a smaller fraction of the total.
> > 
> > Yes, it makes it all a little more cumbersome, but we should really not
> > burden everybody with the load of some.
> > 
> > Surely there is another solution... ?
> Thanks, agree with you, I try do it in other ways :)

One option is to first flip the static key and then iterate all existing
tasks, allocating the memory structure. New tasks will get it allocated
per the static key, existing tasks will get it allocated per the
iteration and dying tasks we don't care about.

That would be sufficient, no?