lkml.org 
[lkml]   [2016]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 5/9] x86/sysctl: Add sysctl for ITMT scheduling feature
On Wed, 5 Oct 2016, Tim Chen wrote:
> On Wed, 2016-10-05 at 16:35 +0200, Thomas Gleixner wrote:
> > > + if (itmt_supported) {
> > > + itmt_sysctl_header =
> > > + register_sysctl_table(itmt_root_table);
> > > + if (!itmt_sysctl_header) {
> > > + mutex_unlock(&itmt_update_mutex);
> > > + return;
> > So you now have a state of capable which cannot be enabled. Whats the
> > point?
>
> For multi-socket system where ITMT is not enabled by default, the operator
> can still decide to enable it via sysctl.

With a sysctl which failed to be installed. Good luck with that.

> > > + }
> > > + /*
> > > +  * ITMT capability automatically enables ITMT
> > > +  * scheduling for small systems (single node).
> > > +  */
> > > + if (topology_num_packages() == 1)
> > > + sysctl_sched_itmt_enabled = 1;
> > > + } else {
> > > + if (itmt_sysctl_header)
> > > + unregister_sysctl_table(itmt_sysctl_header);
> > > + }
> > > +
> > > + if (sysctl_sched_itmt_enabled) {
> > > + /* disable sched_itmt if we are no longer ITMT capable */
> > > + if (!itmt_supported)
> >
> > How do you get here if itmt is not supported? 
>
> If the OS decides to turn off ITMT for any reason, (i.e. invoke 
> sched_set_itmt_support(false) after it has turned on itmt_support
> before), this is the logic to do it.  We don't turn off ITMT support
> after it has been turned on today, in the future the OS may.

Then please make this two functions (set/clear) so one can actually follow
the logic. The above is just too convoluted.

Thanks,

tglx
\
 
 \ /
  Last update: 2016-10-06 13:16    [W:0.147 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site