linux-kernel - Re: [PATCH -mm 2/2] cgroup: use multibuf for tasks file

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: <48CF1710.20907@cn.fujitsu.com>
Date:	Tue, 16 Sep 2008 10:16:48 +0800
From:	Li Zefan <lizf@...fujitsu.com>
To:	Lai Jiangshan <laijs@...fujitsu.com>
CC:	Paul Menage <menage@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -mm 2/2] cgroup: use multibuf for tasks file

Lai Jiangshan wrote:
> Paul Menage wrote:
>> On Fri, Sep 12, 2008 at 4:55 AM, Lai Jiangshan <laijs@...fujitsu.com> wrote:
>>> when we open a really large cgroup for read, we may failed
>>> for kmalloc() is not reliable for allocate a big buffer.
>> This still depends on an answer to whether using plain vmalloc is too
>> much overhead.
>>
>> Balbir pointed out to me that most cgroups are likely to be pretty
>> small - so the solution of just doing a kmalloc() for 8K or less, and
>> a vmalloc() for more than 8K (which is >2000 threads) will avoid the
>> vmalloc overhead in almost all cases; the question is whether
>> eliminating the remaining overhead is worth the extra complexity.
>>
> 
> I think open cgroup.tasks to read is not a critical path.
> so using plain vmalloc(even more overhead functions) is worth.
> 

This patch does not only add runtime overhead, but also make code much more
complex, so the code is harder to read and harder to maintain, and object size
is increased, which means increased memory footprint.

And is there any reason not using plain vmalloc? Don't bloat the kernel without
good reasons IMO...
--
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/