buddy algorithm

buddy algorithm

[Martin Herrman]

Hi all,

first I want to give a short introduction about myself. I'm a 22 year old
student computer sience at Eindhoven University of Technology, which is
located in the south of The Netherlands, Europe. I'm using Linux as
desktop and server operating system since about 3 years now. I like
motorcycles, beer and most important: I like my girlfriend :-) More about
me at http://tuxserver.dyndns.org

Now let's get to the point why I subscribed to this mailinglist: I'm
taking a course 'The Linux Kernel' at the moment and together with a
friend I have to find a nice assignment with which we will (probably :-)
pass the course. We heard about the 'buddy algorithm', which assigns
memory to processes. Now the question is: how does the ELKS project deal
with it? Does it use the same algorithm as the official linux kernel does?
Is there any interest in a different version of the algorithm which uses
fibonacci to assign memory parts to processes if they ask for it? The
fibonacci way (1,1,2,3,5,8,13, etc.) will cost some speed (compared to
1,2,4,8,16, etc.), but will yield some better utilisation of available
memory.

I'm really looking forward to your replies!

Martin

-- 
 Bezoek http://tuxserver.dyndns.org :
 Linux Gebruikers Handleiding, GS500, SV650

Re: buddy algorithm

[Dan Olson]

I was under the impression that ELKS assigns 64k to each process, so a
single 16 bit data pointer can be used and the different segments can be
simply divided so that each process owns one.  There are others on the
list with much more knowledge about this, though, so I'll wait for one of
them to clear things up.

	Dan


On Fri, 10 Jan 2003, Martin Herrman wrote:

> Hi all,
>
> first I want to give a short introduction about myself. I'm a 22 year old
> student computer sience at Eindhoven University of Technology, which is
> located in the south of The Netherlands, Europe. I'm using Linux as
> desktop and server operating system since about 3 years now. I like
> motorcycles, beer and most important: I like my girlfriend :-) More about
> me at http://tuxserver.dyndns.org
>
> Now let's get to the point why I subscribed to this mailinglist: I'm
> taking a course 'The Linux Kernel' at the moment and together with a
> friend I have to find a nice assignment with which we will (probably :-)
> pass the course. We heard about the 'buddy algorithm', which assigns
> memory to processes. Now the question is: how does the ELKS project deal
> with it? Does it use the same algorithm as the official linux kernel does?
> Is there any interest in a different version of the algorithm which uses
> fibonacci to assign memory parts to processes if they ask for it? The
> fibonacci way (1,1,2,3,5,8,13, etc.) will cost some speed (compared to
> 1,2,4,8,16, etc.), but will yield some better utilisation of available
> memory.
>
> I'm really looking forward to your replies!
>
> Martin
>
> --
>  Bezoek http://tuxserver.dyndns.org :
>  Linux Gebruikers Handleiding, GS500, SV650
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: buddy algorithm

[Harry Kalogirou]

> I was under the impression that ELKS assigns 64k to each process, so a
> single 16 bit data pointer can be used and the different segments can be
> simply divided so that each process owns one.  There are others on the
> list with much more knowledge about this, though, so I'll wait for one of
> them to clear things up.
> 
> 	Dan

ELKS assigns to the process an initial amount of memory for the stack.
From there that memory is grown as the libc instructs with sys_brk()
calls. 

Harry

Re: buddy algorithm

[Alan Cox]

On Fri, 2003-01-10 at 22:16, Martin Herrman wrote:
> pass the course. We heard about the 'buddy algorithm', which assigns
> memory to processes. Now the question is: how does the ELKS project deal
> with it? Does it use the same algorithm as the official linux kernel does?

ELKS draws on v7 and on Minix for its origins. It takes an old v7 unix
type view of kernel dynamic memory allocators (that is -don't do it-),
user space memory is handled by a simple linked list of holes. We have
two entries per process maximum (data and code) so kernel side its just
not worth the clever stuff.

Much of the other ELKS stuff is like this. We have no hash for the
buffer cache because we tend to have about ten buffers cached...