Linux-kernel mailing list archive 1997-11,: Re: fork: out of memory

# Re: fork: out of memory

Zlatko Calusic (Zlatko.Calusic@CARNet.hr)
25 Nov 1997 12:23:51 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Alan Donald: "Re: Recommendations for 100Mbit Ethernet Card"
- Previous message: Ingo Molnar: "Re: fork: out of memory"
- In reply to: Alan Cox: "Re: fork: out of memory"
- Next in thread: Andi Kleen: "Re: fork: out of memory"
- Reply: Andi Kleen: "Re: fork: out of memory"

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.

- Next message: Alan Donald: "Re: Recommendations for 100Mbit Ethernet Card"
- Previous message: Ingo Molnar: "Re: fork: out of memory"
- In reply to: Alan Cox: "Re: fork: out of memory"
- Next in thread: Andi Kleen: "Re: fork: out of memory"
- Reply: Andi Kleen: "Re: fork: out of memory"