Messages in this thread | | | Date | Mon, 20 Jul 1998 11:38:21 +0100 | From | Jamie Lokier <> | Subject | Re: Memory Rusting Effect [re: Linux hostile to poverty] |
| |
On Mon, Jul 20, 1998 at 09:38:00AM +0100, Alan Cox wrote: > > Folks, increased functionality and/or increased performance almost always > > means increased memory footprint. There's no fix for that yet, as long as > > the kernel itself can't be swapped (and I don't think we want to deal with > > the *nasty* potential deadlocks inherent in swappable kernel memory!). > > I think people exaggerate how hard that is. I've had bits of this sort of > working in 2.1.x earlier. So long as you only touch interface code that > is not itself involved in swapping and which can tolerate sleeping - of > which much of the config side code is an obvious candidate then you can > merge it all together by borrowing the initfunc trick and having > > __swappable(int somedev_complexioctl(...))
With all the current problems of memory rust etc., are we really sure swapping kernel pages will improve performance ;-) And I'm thinking I rather like that the network stack keeps responding to ARP and ping when the system is otherwise thrashing.
It makes me wonder if there isn't an automatable way to trace which variables and functions are used by interrupts and paging, leaving the rest to be swapped. Likewise for initfunc.
Vice versa, if any function calls something that may sleep, apart from code called from the page fault handler, is that a safe bet for __swappable?
You have to be _really_ careful about this for the char stream devices -- who knows what's in use for swapping over NFS/nbd over PPP over a serial line :-) [Ok, nobody sane would do it but it's technically configurable]. Again for network devices. Though probably you wouldn't want to make the critical parts swappable anyway.
I noticed user space applications and DJGPP drivers have to use mlock to do this sort of thing the other way, and they often get it wrong. It can be tricky remembering to mlock every local static variable, string and malloc'd area used from an interrupt.
I just noticed there's about 660k code reported for my kernel (this includes exception tables etc.). The modules I have loaded right now take up another ~228k (going by the sizes listed by lsmod, rounded up to the next 4k). A measly 28k is reported at boot time as initialisation code.
Is it feasible to remove __initfunc and __initdata memory for modules after they've initialised?
How much could be saved by making some kmalloc'd memory swappable?
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |