lkml.org 
[lkml]   [1998]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

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