On Mon, Feb 02, 2015 at 02:35:41PM -0800, Andrew Morton wrote:
> On Mon, 2 Feb 2015 22:18:24 +0000 Mel Gorman <mgor...@suse.de> wrote:
>
> > > Is there something
> > > preventing this from being addressed within glibc?
> >
> > I doubt it other than I expect they'll punt it back and blame either the
> > application for being stupid or the kernel for being slow.
>
> *Is* the application being stupid? What is it actually doing?
Only a little. There is little simulated think time between the allocation
and the subsequent free. It means the cost of alloc/free dominates where
in "real" applications they would either be reusing buffers if they were
constantly needed or the think time would mask the cost of the free.
> Something like
>
> pthread_routine()
> {
> p = malloc(X);
> do_some(work);
> free(p);
> return;
> }
>
Pretty much. There is a search_mem() function that
alloc(copy_size)
memcpy
search
free(copy)
A real application might try and avoid the copy or reuse buffers if they
encountered this particular problem.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
