lkml.org 
[lkml]   [1997]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: fork: out of memory
From
Date
alan@lxorguk.ukuu.org.uk (Alan Cox) writes:

> > Maybe it would be a wise idea to make few pointers instead of
> > fd[NR_OPEN]. Every pointer would point to a smaller table of let's say
> > 64 file descriptors and would be allocated as needed. First such table
> > would be in files_struct itself.
>
> Its very important to be able to do the files check fast. What seems
> more sane to me is
>
> struct files_struct
> {
> int count;
> int limit;
> fd_set close_on_exec;
> fd_set open_fds;
> struct file *fd[0]
> };
>
> and to allocate initially on a 64 fd break point. So you malloc
> one files_struct + 64 * (struct file *). That does however requre
> you write the code atomically and safely handle growing the file table
> - which is actually quite hard if you want speed.
>

Well, I'm currently researching throughout the kernel, finding
misterious places where files_struct is directly or indirectly used.
Definitely lots of places. :)

My idea is to put:

int curr_max_fd; and
struct file **fds; (instead of *fd[NR_OPEN])

and then allocate first set of 64 struct file * (as you suggested,
too).

Later, when I ran out of fd's, I would allocate next (256 - 64)
pointers. And if even that isn't enough, (1024 - (256 - 64)).

These extra allocations would go to get_unused_fd() in fs/open.c.
I didn't find any other place (but I just started working on it, it will
take some time).

Some preliminary searching showed me that I will have to modify at
least 50 files!!! No big things, but absolutely neccessary if you ask
me (unless I have problems in logic :)).

Now the question:
When you say "atomically" do you mean "in one place" or with
GFP_ATOMIC? I understand differences between *_KERNEL and *_ATOMIC,
but... I'm not sure which one should be used in this case.

My vote for kmalloc(x, SLAB_KERNEL). :)
But, maybe I should doublecheck.
Well, whatever, my system will be first in line for corruptions. :)

Regards,
--
Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr>
---------------------------------------------------------------------
No sense being pessimistic. It wouldn't work anyway.

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