lkml.org 
[lkml]   [1998]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: New Feature Idea: Compress swap file
Date
And lo, Stefan Monnier saith unto me:
> MOLNAR Ingo <mingo@chiara.csoma.elte.hu> wrote:
> > On 20 Feb 1998, Stefan Monnier wrote:
> > > All in all, unrealizable within Unix, but probably doable in a
> > > (non-conservatively) GC'd world (since the GC already knows what is a
> > > pointer and what is not and is able to move objects at will). LISP
> > > machines, Smalltalk machines, or JavaOS would probably be good systems
> > > to try it on.
> > Maybe unrealizable within Unix and NT, but not within Linux ;)
>
> Moving objects is very hard to do if you want to allow C programs that
> do "strange" pointer casts (in other words, 99.99% of all C programs).
> I believe a Linux hack that would prevent Linux from providing full C
> support would be very unpopular.
You already have a VM mechanism in place for the user space, so there's
no call for that (you don't change the virtual address when you (de)com-
press, as when you page in or out). The only C programs under Linux which
care about physical (and physically contiguous) addresses are the
Linux kernel itself, plus modules, plus hardware device drivers (to
compress something a board is about to DMA out of core would suck).

Even there, the effort isn't really worth the reward (especially as
code adapts to the fact that nobody who knows how to implement memory
defragmentation will have time to do so before they finish fixing the
year 2038 bugs a few days ahead of the end of the epoch.


> Also the description of what is a pointer and what is not has to be known
> by the swap/compress code which amounts to standardizing it: most GC'd
> languages use their very own scheme and even the debug info (which
> could be used for more traditional languages like Fortran/C/Pascal)
> is not well standardized.
You don't want to do this to stuff used by the kernel; the hassle and
added latency isn't worth it, especially since you also have to tell
what can/can't be delayed by the compression, and what can't be
compressed because a device will do I/O there. You only want to
compress user-space pages, which even the kernel accepts may entail
a page fault to access, and even then only those pages which aren't
mlocked (and possibly also not mmapped either).

> Maybe not unrealizable within Unix or Linux, but very hard to make it
> work transparently.
Anything looks transparent if you hide it behind the VM layer. The fix
for any other methodology is "don't do that, then".

Keith


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans