RE: [Xen-devel] big local array in routine in hypervisor

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> Does it *really* have to be multi-page contiguous? You 
> couldn't for example
> build your workspace out of a radix tree with page-sized leaves?
> Or are you saying that maybe you can't allocate even a single 
> page, or a
> sub-page? In that case it would seem memory is so tight you 
> have little
> choice but to pre-reserve.

I'm trying to use the lzo compression code now in Linux
(as of 2.6.27 I think) in linux/lib/lzo.  It uses a large
static work area... which now that I look more carefully
is actually 128kB!...  apparently ffs2 (its sole user in
Linux as of now) doesn't care about SMP?

> So you want us to wastefully pre-reserve some space for you, 
> but call it the
> 'stack' to assuage your guilt? ;-)

Point taken ;-)  But the stack can be used by others and
my pre-reserved space could not.

> It's common practice not to have very
> large stacks in kernels, since pre-reservation is wateful, 
> dynamic growth is not necessarily feasible to implement,
> and kernel code doesn't tend to need lots of local storage
> or recursion. In Linux you'd be limited to 4kB, and
> there's a lot more code there living under that stricter regime.

True, but the history of most kernels goes back a bit farther
than Xen's, back when memory density and cost was a factor
of 1000x different.  So... 4kb * 1000 is 4M ;-)

> It's a slippery slope though, determining how much stack is 
> enough and how
> big a local array is too big. I generally end up having to 
> check and fix big
> stack frames from time to time, and I'm not sure that even 
> doubling the
> stack a few times would avoid that job!

Agreed.  It will never be enough.

I'll live with the private static array for now.

Dan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel