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]
Message-Id: <20081127134334.3CE1.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date:	Thu, 27 Nov 2008 21:50:16 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	kosaki.motohiro@...fujitsu.com,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	Ingo Molnar <mingo@...e.hu>, ltt-dev@...ts.casi.polymtl.ca,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	William Lee Irwin III <wli@...omorphy.com>
Subject: Re: [ltt-dev] [PATCH] Poll : introduce poll_wait_exclusive() new function

> > One of the key design rule of LTTng is to do not depend on such
> > system-wide data structures, or entity (e.g. single manager thread).
> > Everything is per-cpu, and it does scale very well.
> > 
> > I wonder how badly the approach you propose can scale on large NUMA
> > systems, where having to synchronize everything through a single thread
> > might become an important point of contention, just due to the cacheline
> > bouncing and extra scheduler activity involved.
> 
> I dunno the LTT architecture, so I'm staying out of that discussion.
> But, if the patch you're trying to push is to avoid thundering herd of so 
> many threads waiting on the single file*, you've got the same problem 
> right there. You've got at least the spinlock protecting the queue 
> where these threads are focusing, whose cacheline is bounced gets bounced 
> all over the CPUs.
> Do you have any measure of the improvements that such poll_wait_exclusive()
> will eventually lead to?

Also my lttng knowledge isn't perfect.
Then, I'd like to talk about another aspect.

This patch was originally written for memory shortage notification to userland patch.
Currently, many application has own various cache (e.g. almost GUI app
has image cache, the VM of the langueage with GC feature has droppable
garbege memory)

However, To wake up all process makes thundering herd easily.
because it wake up almost process in system.
In addision, any process independent on each other. then, I couldn't 
choice your proposed workaround at that time.

Currently, we and container folks restart to discuss cgroup 
oom notification again.
I think this patch can provide its infrastructure too.

if possible, Could you please don't only review description,
but also the code?



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

Powered by Openwall GNU/*/Linux Powered by OpenVZ