[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55C4C35A.4070306@zonque.org>
Date: Fri, 7 Aug 2015 16:40:26 +0200
From: Daniel Mack <daniel@...que.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: David Herrmann <dh.herrmann@...il.com>,
Tom Gundersen <teg@...m.no>,
"Kalle A. Sandstrom" <ksandstr@....fi>,
Greg KH <gregkh@...uxfoundation.org>,
Borislav Petkov <bp@...en8.de>,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Havoc Pennington <havoc.pennington@...il.com>,
Djalal Harouni <tixxdz@...ndz.org>, cee1 <fykcee1@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: kdbus: to merge or not to merge?
On 08/06/2015 08:43 PM, Andy Lutomirski wrote:
> Nonetheless, it looks like the slice logic (aside: it looks *way* more
> complicated than necessary -- what's wrong with circular buffers)
> will, under most (but not all!) workloads, concentrate access to a
> smallish fraction of the pool. This is IMO bad, since it means that
> most of the time most of the pool will remain uncommitted. If, at
> some point, something causes the access pattern to change and hit all
> the pages (even just once), suddenly all of the pools get committed,
> and your memory usage blows up.
That's a general problem with memory overcommitment, and not specific to
kdbus. IOW: You'd have the same problem with a similar logic implemented
in userspace, right?
Daniel
--
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