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]
Date:	Thu, 26 Aug 2010 11:49:43 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Nick Piggin <npiggin@...nel.dk>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jonathan Corbet <corbet@....net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Al Viro <viro@...iv.linux.org.uk>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lglock: make lg_lock_global() actually lock globally

Hello,

On 08/26/2010 11:46 AM, Nick Piggin wrote:
> Oh, I thought we quiesce / preempt all online cpus before adding
> another one. That sucks if we don't because then you need a big
> heavy get_online_cpus when a simple preempt_disable would have
> worked.
> 
> Why is that? Don't tell me realtime people want some latency "guarantee"
> while onlining CPUs? :)

Probably similar rationale of not doing stop_machine() on module
unload, I suppose.  Onlining something is usually considered hotter
path than offlining.  Performance penalty caused by the difference
between possible and online cpumask or cpu onlining probably only
matters for very large machines and on those machines stop-machine is
very expensive.  If there's a pressing need, doing stop_machine for
onlining too is definitely an option.

>> So, yeah, given that there's no cpu notifier implemented, the use of
>> for_each_online_cpu for brlock seems fishy to me.  It probably should
>> use for_each_possible_cpu().
> 
> It should if that's the case, yes.

IMHO, in most configurations the difference between possible and
online cpumasks doesn't matter much (they're the same during normal
operation), so just using possible cpumask should be fine.  It's
already a pretty heavy path, right?

Thanks.

-- 
tejun
--
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