* buddy algorithm [not found] <20030110214652Z266323-22911+21374@vger.kernel.org> @ 2003-01-10 22:16 ` Martin Herrman 2003-01-10 22:36 ` Dan Olson 2003-01-11 2:41 ` Alan Cox 0 siblings, 2 replies; 4+ messages in thread From: Martin Herrman @ 2003-01-10 22:16 UTC (permalink / raw) To: linux-8086 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: buddy algorithm 2003-01-10 22:16 ` buddy algorithm Martin Herrman @ 2003-01-10 22:36 ` Dan Olson 2003-01-10 22:37 ` Harry Kalogirou 2003-01-11 2:41 ` Alan Cox 1 sibling, 1 reply; 4+ messages in thread From: Dan Olson @ 2003-01-10 22:36 UTC (permalink / raw) To: Martin Herrman; +Cc: linux-8086 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 > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: buddy algorithm 2003-01-10 22:36 ` Dan Olson @ 2003-01-10 22:37 ` Harry Kalogirou 0 siblings, 0 replies; 4+ messages in thread From: Harry Kalogirou @ 2003-01-10 22:37 UTC (permalink / raw) To: Dan Olson; +Cc: Martin Herrman, Linux-8086 > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: buddy algorithm 2003-01-10 22:16 ` buddy algorithm Martin Herrman 2003-01-10 22:36 ` Dan Olson @ 2003-01-11 2:41 ` Alan Cox 1 sibling, 0 replies; 4+ messages in thread From: Alan Cox @ 2003-01-11 2:41 UTC (permalink / raw) To: Martin Herrman; +Cc: linux-8086 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... ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-01-11 2:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20030110214652Z266323-22911+21374@vger.kernel.org>
2003-01-10 22:16 ` buddy algorithm Martin Herrman
2003-01-10 22:36 ` Dan Olson
2003-01-10 22:37 ` Harry Kalogirou
2003-01-11 2:41 ` Alan Cox
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox