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-next>] [day] [month] [year] [list]
Message-ID: <20160316074123.GP6344@twins.programming.kicks-ass.net>
Date:	Wed, 16 Mar 2016 08:41:23 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Michael Turquette <mturquette@...libre.com>
Cc:	rjw@...ysocki.net, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org, Juri.Lelli@....com,
	steve.muckle@...aro.org, morten.rasmussen@....com,
	dietmar.eggemann@....com, vincent.guittot@...aro.org,
	Michael Turquette <mturquette+renesas@...libre.com>
Subject: Re: [PATCH 5/8] sched/cpufreq: pass sched class into
 cpufreq_update_util

On Tue, Mar 15, 2016 at 03:06:09PM -0700, Michael Turquette wrote:
> Quoting Peter Zijlstra (2016-03-15 14:25:20)
> > On Sun, Mar 13, 2016 at 10:22:09PM -0700, Michael Turquette wrote:
> > > +++ b/include/linux/sched.h
> > > @@ -2362,15 +2362,25 @@ extern u64 scheduler_tick_max_deferment(void);
> > >  static inline bool sched_can_stop_tick(void) { return false; }
> > >  #endif
> > >  
> > > +enum sched_class_util {
> > > +     cfs_util,
> > > +     rt_util,
> > > +     dl_util,
> > > +     nr_util_types,
> > > +};
> > > +
> > >  #ifdef CONFIG_CPU_FREQ
> > >  struct freq_update_hook {
> > > +     void (*func)(struct freq_update_hook *hook,
> > > +                  enum sched_class_util sched_class, u64 time,
> > >                    unsigned long util, unsigned long max);
> > >  };
> > >  
> > Have you looked at the asm that generated? At some point you'll start
> > spilling on the stack and it'll be a god awful mess.
> > 
> 
> Is your complaint about the enum that I added to the existing function
> signature, or do you not like the original function signature[0] from
> Rafael's patch, sans enum?

No, my complaint is more about the call ABI for all our platforms, at
some point we start passing arguments on the stack instead of through
registers.

I'm not sure where that starts hurting, but its always a concern when
adding arguments to functions.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ