[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190823173338.GA18880@lenoir>
Date: Fri, 23 Aug 2019 19:33:39 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
John Stultz <john.stultz@...aro.org>,
Anna-Maria Behnsen <anna-maria@...utronix.de>,
Christoph Hellwig <hch@....de>
Subject: Re: [patch V2 20/38] posix-cpu-timers: Provide array based access to
expiry cache
On Wed, Aug 21, 2019 at 09:09:07PM +0200, Thomas Gleixner wrote:
> Using struct task_cputime for the expiry cache is a pretty odd choice and
> comes with magic defines to rename the fields for usage in the expiry
> cache.
>
> struct task_cputime is basically a u64 array with 3 members, but it has
> distinct members.
>
> The expiry cache content is different than the content of task_cputime
> because
>
> expiry[PROF] = task_cputime.stime + task_cputime.utime
> expiry[VIRT] = task_cputime.utime
> expiry[SCHED] = task_cputime.sum_exec_runtime
>
> So there is no direct mapping between task_cputime and the expiry cache and
> the #define based remapping is just a horrible hack.
>
> Having the expiry cache array based allows further simplification of the
> expiry code.
>
> To avoid an all in one cleanup which is hard to review add a temporary
> anonymous union into struct task_cputime which allows array based access to
> it. That requires to reorder the members. Add a build time sanity check to
> validate that the members are at the same place.
>
> The union and the build time checks will be removed after conversion.
>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Reviewed-by: Frederic Weisbecker <frederic@...nel.org>
Powered by blists - more mailing lists