lkml.org 
[lkml]   [1998]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH: smart symlink loop detection.

On Thu, 16 Apr 1998, C. Scott Ananian wrote:
> On Thu, 16 Apr 1998, Adam D. Bradley wrote:
> > (That's one more reason why the linked list idea seems more managable,
> > if less efficient in the general case. Plus it makes inserts and
> > deletes trivial compared with having to do potentially huge and
> > CPU-sucking string copies for every step of a symlink expansion...)
>
> I have to confess that I'm not overly familiar with the workings of
> kmalloc. My impression was that the kernel uses a simple (but fast)
> allocator that gives you chunks of BLOCK_SIZE bytes, whether you need it
> all or not. So, in the worst case (I don't know how large BLOCK_SIZE is)
> you could end up allocating huge amounts of memory for the linked list
> scheme.

Hmm... a quick look through the slab allocator code (mm/slab.c) shows
that kmalloc keeps cached pools of chunks with sizes of powers-of-2,
starting with 32 (64 on 64-bit architectures). If we allocate the
list elements on-the-fly and including the string as a static piece
(the old "char name[0]" as last element trick), then space shouldn't
be too much of a problem.

A greater concern is latency: __kmem_cache_{alloc,free} are the
underlying routines, and are protected by spinlocks. Does anyone out
there have hard numbers (cycle counts, "10000 iterations took X
milliseconds", etc) on these functions?

Adam
--
You crucify all honesty \\Adam D. Bradley artdodge@cs.bu.edu
No signs you see do you believe \\Boston University Computer Science
And all your words just twist and turn\\ Grad Student and Linux Hacker
Reviving just to crash and burn \\ <><
---------> Why can't you listen as love screams everywhere? <--------


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.089 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site