Messages in this thread | | | Date | Fri, 19 Sep 2008 04:52:12 +0900 | From | KOSAKI Motohiro <> | Subject | Re: [PATCH -mm 2/2] cgroup: use multibuf for tasks file |
| |
> Li Zefan wrote: > > Lai Jiangshan wrote: > >> Paul Menage wrote: > >>> On Fri, Sep 12, 2008 at 4:55 AM, Lai Jiangshan <laijs@cn.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... > > > > I said that vmalloc is worth. > vmalloc was the fist choice of my opinion. ^_^
I agreed with Paul Menage's opinion because ..
- plain vmalloc cause unnecessary overhead. - vmalloc sholdn't use for small allocation because virtual address space is valuable resource on 32bit machine.
| |