On Fri, May 26, 2000 at 10:59:53AM -0400, John V . Baboval wrote:
> On Fri, May 26, 2000 at 02:05:24AM +0200, Andi Kleen wrote:
> > kmalloc cannot allocate >128K, and that is very unreliable; better use vmalloc
> > for >2*PAGE_SIZE
>
> I wasn't sure about the maximum size you could kmalloc... Is the 128K limit
> based on the page size in some way, or is that a hard limit across all
> platforms. I'd like to try for the kmalloc if there's any hope of it
> succeeding at all so that the performance hit the profiler causes is
> minimized. Unfortunatly, with the average kernel build, a profile buffer
> will never be < 128K if you want decent resolution in your profile...
At runtime any allocation >2 pages is unreliable because of fragmentation.
At boot time it is often possible to allocate more.
128K is the biggest slab in the slab kmalloc emulation, so it is a hard limit.
When you want to change at runtime you don't have much alternative to
vmalloc.
>
> >
> > I also have my doubts that the per process name is that useful, because
> > the linux kernel does a lot of things asynchronously outside process context.
>
> Do you have any suggestions as to something that would be more helpful for
> finding performance bottlenecks on production machines with multiple
> functions? I'm guessing that you're thinking of things like kswapd as
> something that is run outside of the processes context...
Anything more useful has too much overhead I think.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:16 EST