| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> Wilson or so
<1> :)
<0> but Doug Lea is also a good starting point
<1> :D I bought the Indespensible PC Hardware book yesterday :D I cant wait until it arrives :D
<0> a simple allocator with boundary tags and freelists
<1> aye.
<1> Memory pools sound cool too
<2> any process will perform memory allocations throughout its life.. there are different types of allocations. some will be brief, others will last a while, some for the duration of the process. some will be small, others will be large.
<0> http://citeseer.ist.psu.edu/wilson95dynamic.html
<2> most programs will be deal with fixed-sized structures often, so you'll see a set of fixed-sized allocations that occur much more often than others
<2> and those specific sizes will also likely have similar lifespans
<2> so an 'excellent'
<2> allocator design takes that into consideration
<2> to minimize the pages held by the process to cover the process's needed memory
<0> right, slab allocators
<0> http://citeseer.ist.psu.edu/bonwick94slab.html
<1> thanks!
<2> ideally the application would tell the allocator the expected duration, or other information to ***ist the allocator. like a precompiled statistical analysis of a typical run's memory allocation patterns
<2> but no, instead we just try to predict it in the least complicated manner
<2> for the sake of simplicity i suppose ;)
<0> mrd: best would be to collect and use statistics, instead of "precompile" them
<2> true
<1> Hhm,
<1> Whats the usual tracking of a single chunk though?
<1> i mean, if we hide the tracking stuff in the block itself
<1> a simple way to kepe track of the last page of hte heap
<1> is .. like.
<1> have bins, like DLeas.
<1> order the chunks on those bins by address.
<0> btw. here's a good start if you didn't already write a malloc: http://g.oswego.edu/dl/html/malloc.html
<1> the highest address is always going to be the heap end.
<3> Zeii: do you want to use an allocator in kernel space or user space ?
<1> Userspace.
<1> KErnelspace is nicely covered.
<0> colyli: does that matter?
<1> I use a Slab concept with respect to kernelspace MM
<4> man, this pop corn needs more salt
<3> undesktop: not much :-)
<0> gr00ber: hope you can affort the salt
<0> or was it "effort"
<4> no prob
<0> no, afford
<1> Think Ill use a modification of the kernel system, but for userspace.
<3> undesktop: but I think the function "customize cache size" of slab in user space is not necessary for popular use
<1> That way the programmer can decide what he wants.
<5> why should a kernel get involved in user app heap management? I thought the point was that user apps call brk(), get an extension to their virtual space, and leave it to the app and its libraries to worry about malloc()ing blocks from the workspace?
<4> it's... i have this fresh hot pop corn and the salt is ten feets away
<1> :)
<1> thanks guys!
<4> and i don't feel like getting away from the kbd
<1> diodesign, precisely.
<1> the poitn though dio
<1> is that...
<1> what if the highest page of that address space is free?
<1> and is a block on the userspace tracking?
<1> youd want to free it
<1> give it back to the system, if possible
<1> for use elsewhere.
<4> free willy!
<0> colyli: depends from the programmer... i.e. some programmers would use "free lists" which is basically the same like a slab allocator
<4> (!.!)
<3> undesktop: I agree with you :-P
<5> Zeii: if the page is unused for a while, then when the system needs to find physical pages from somewhere, it can map out old pages
<5> I see where you're coming from, though
<1> :)
<4> wherefrom?
<1> The kernel uses a cool but crazy MM approach
<0> colyli: :-)
<1> Ill use a Slab system.
<5> it's easy to do this on x86 which maintains reference bits for page entries. but on ARM, the MMU doesn't appear to do this (well, certainly not for the ARM9 and SA110 I have) so I'm having to do what you're doing
<3> undesktop: indeed, maybe months later, I will also encounter the user space heap allocator :-)
<1> Well, I cant page the data to disk, just yet.
<1> Kernel doesnt have that functionality and never will.
<1> ;) Slab concept simplifies it nicely :D
<1> :) Thanks!
<1> Im going off to tinker :)
<5> cya
<1> Have fun people.
<2> dio, so how do you find old pages? do you just randomly swap pages, or do you randomly mark pages as unavailable and track through page faults?
<5> on, what, ARM?
<2> anything without dirty bits
<0> doesn't every ARM CPU has a different MMU
<5> swap out areas that are old at random
<5> areas tha come straight back off the disc get a new timestamp
<2> do you have any kind of intel to help determine age? oh you track by allocation/page fault time
<5> yeah, track by allocation time and how quickly they're pulled out of swap again
<5> not entirely ideal
<2> couldn't you mark them as unavailable just to track page faults, without actually recycling the page unless it is needed
<2> if you reduced the frequency, you could induce minimal overhead while getting better usage statistics
<6> it might be good to have a cache that pages go to before being swapped to disk a little later& so when a page is expired it is still in ram and a fault can pull it back very quickly, and it can also get you some useful profiling information without having too many page faults and disk accesses
<6> linux does this i'm pretty sure
<6> probably most popular kernels actually
<5> as in, the mm has N areas it'd like to swap out, and before it tags one to be swapped to disc, it tests the water by marking the pages as inaccesible and sees which ones fault because they're still in use?
<5> I like that. that's cunning.
<6> exactly
<5> :)
<3> undesktop: why you say "wrong API" for L4 ?
<0> isn't that called "second chance algorithm" or so
<0> colyli: because the API is great for kernel implementers, but ****s for users
<0> colyli: same for performance
<5> this is a reference bit/cache hybrid ;)
<3> undesktop: do you mean the API of L4 make performance suffer ?
<0> colyli: yes, if you want reasonable security
<6> undesktop: have you looked at L4.sec?
<0> geezusfreeek: well, I only saw some power point slides
<3> undesktop: oh, this is the first time I hear of this, thank you :-)
<0> I think there'a also a diploma thesis now
<0> colyli: look at Mach/L4
<0> errrm
<0> Hurd/L4
<3> undesktop: I dont like these kind of stuffs, L4hurd, L4linux
<0> they wanted to port the Hurd to L4, but then they gave up, because of the L4 API
<6> i wouldn't say that L4's api limits users& the kernel isn't supposed to be the whole of the operating system
<0> colyli: huh? Hurd/L4 was only an attempt to implement a microkernel on L4
<3> undesktop: for I think L4 need a set of native implementation for lib and driver ...
<0> colyli: they didn't do Mach emulation or so
<3> undesktop: do you mean L4hurd is different to L4linux ?
<3> I mean the idea
<3> make a linux or hurd kernel run under user space ?
<0> yes
<0> in L4/Linux, Linux runs as single server
<3> undesktop: yes, go ahead please
<0> that's totally different from Hurd, which is distributed over many servers...
<6> l4hurd's goal is basically to replace Mach with L4
<0> right, but in reality, they had to rewrite large parts of Hurd
<6> i don't see that working mainly because of the crazy differences between mach and l4
<3> undesktop: oh! I see, that's a lot of work
<6> it's like trying to port os x from xnu to L4 or something& too much difference
<6> well, xnu to L4 would probably be even worse :P
<0> anyway... they want to use Coyotos now
<3> undesktop: indeed, I always think L4 needs a native network stack and other stuffs
<0> instead of L4... I think they also considered L4.sec
<0> colyli: that isn't the problem
<0> colyli: the network stack is already implemented by Hurd
<3> undesktop: current solution (run a legacy on top of the L4) is slow
<0> colyli: as any kernel should
<0> colyli: microkernel means micro
<3> undesktop: but L4 has no
<0> L4 is a microkernel... no network, no drivers
<3> undesktop: yes ...
<0> colyli: if you don't want a microkernel, then don't look at them
<3> undesktop: I only see the l4linux demo
<3> which uses linux network stack to serve
<0> it uses _everything_ from Linux
<3> undesktop: yes, I do want to make my hobby os as a microkernel
<3> undesktop: yes, almost everything, so I think this is kind of performance killer
<0> wellwellwell
<0> I think the reason they did this was the following: in this way, you can on one hand implement a sure real time L4 server and such, and on the other hand use all features of Linux
<3> undesktop: if L4 improves its API, do you think it will be better ?
<3> just for granted
Return to
#osdev
or
Go to some related
logs:
#css
#perl
#gentoo
openbsd bcm43
jkauffman
changing root password mysql 5.0.22
#ubuntu
/easyhealer option
amsn versus kopete
#perl
|
|