lkml.org 
[lkml]   [1996]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Please don't beat me up (was Re: Bugs and wishes in memory management area)
Date

>If I remember correctly, the primary argument against this was the
>performance penalty of invalidating the cache after every kernel
>memory allocation. Besides which, it was pretty gross compared to the
>superefficient buddy system.

The buddy system is pretty gross for what we want. You don't need
to pull gross hacks with page tables or use complex algorithms
to handle memory allocation though!

I've been working on improved page allocation and kmalloc that
doesn't have nasty power-of-two limits, doesn't thrash any more
than necessary and is optimised for the common case. It's a slow
job because at this stage each little change needs careful thought
and a couple of hours benchmarking to see what effect it has. We are
talking a few microseconds variation but this code is called a lot.

Mike

--
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:mike@roan.co.uk |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'


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