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  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:	Mon, 07 Apr 2014 07:04:50 +0200
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, Tejun Heo <tj@...nel.org>,
	Li Zefan <lizefan@...wei.com>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Linaro Networking <linaro-networking@...aro.org>,
	Arvind Chauhan <Arvind.Chauhan@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>
Subject: Re: [PATCH V2 0/8] cpusets: Isolate CPUs via sysfs using cpusets

On Mon, 2014-04-07 at 09:41 +0530, Viresh Kumar wrote: 
> Hi Mike,
> 
> On 6 April 2014 14:00, Mike Galbraith <umgwanakikbuti@...il.com> wrote:
> > I wonder if adding a quiesce switch is really necessary.
> >
> > Seems to me that if you don't have load balancing turned off, you can't
> > be very concerned about perturbation, so this should be tied into the
> > load balancing on/off switch as an extension to isolating cores from the
> > #1 perturbation source, the scheduler.
> 
> Its more about not doing any background activities on these CPU which can
> be avoided. So, even if a add_timer() is issued from these isolated CPUs, it
> should goto the set chosen for doing background activity, unless add_timer_on()
> has been issued, in which case user wants that code to execute on the
> isolated core.
> 
> Probably, yes, people would be disabling load_balancing between these
> cpusets to avoid migration of tasks to isolated core as well.. Atleast we
> are using it :)

Yes, that's the whole point I'm trying to make.  If you do not have
cores isolated, there's no point to quiesce, as timers and whatnot are
the least of your worries.  Conversely, why would you bother isolating
cores if you didn't want a nice quiet environment.  Seems to me full
isolation ala killing sched domains implies that your goal is bare
metal.. or as close as you can get to that anyway.

> > I also didn't notice a check for is_cpu_exclusive() at a glance, which
> > would be a bug, but one that would go away if this additional isolation
> > were coupled to the existing isolation switch.
> 
> Yeah, there is no check for that. But I didn't got your point completely.
> Why do I need to check for exclusivity on the isolated CPUs? So, that
> same CPU isn't isolated as well as non-isolated on two separate sets?

Yes, both on and off is kinda hard to do per cpu :)

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists