Re: efficacy of Linux w/o swap
From: Nix (nix-razor-pit_at_esperi.org.uk)
Date: 05/16/05
- Next message: phil-news-nospam_at_ipal.net: "Re: efficacy of Linux w/o swap"
- Previous message: James McIninch: "Re: efficacy of Linux w/o swap"
- In reply to: phil-news-nospam_at_ipal.net: "efficacy of Linux w/o swap"
- Next in thread: phil-news-nospam_at_ipal.net: "Re: efficacy of Linux w/o swap"
- Reply: phil-news-nospam_at_ipal.net: "Re: efficacy of Linux w/o swap"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 16 May 2005 13:55:09 +0100
On 16 May 2005, phil-news-nospam@ipal.net spake:
> One issue that I've experienced plaguing Linux in the past (especially
> in many early 2.4 kernels) is that heavy writing to disk resulted in
> large scale caching of the written data in RAM, resulting in fewer
It also blocked reads and writes by other processes :/
> usable RAM pagses for process VM, resulting in more processes being
> swapped out. When I tested these scenarios with swap disabled, things
> actually got worse, rather than better. It seems the caching still was
> being done, but this time the kernel choked on RAM being totally full
> and spent large amounts of CPU doing some kind of activity looking for
> available pages. The way I observed this was through virtual console
> (X was not running) switching. When I was in tty1 and pressed Alt-F2
> to go to tty2, it would pause and not switch for quite some time, then
> evetually complete the switch. Worst case event took 2.5 minutes.
>
> Are these problems definitely cured in 2.6 at least at the current
> versions?
Well, one problem with 2.4 was that the kernel only had mappings from
virtual->physical addresses, so when memory was tight it had to iterate
through hordes of pages looking for just a few to swap out.
In 2.6, an inverse mapping is maintained, making identifying pages to
swap in very-low-memory situations much more CPU-efficient. I've noticed
no kswapd-caused pauses in 2.6; nor have I noticed the 2.4 problem that
a cache full of massive numbers of dirty pages being written to a slow
device blocks *all* writes to *all* devices... I think the problem there
was the block device request queues, but I'm not sure.
Plus, in 2.6 there are a variety of disk schedulers. You probably want
CONFIG_IOSCHED_DEADLINE (for must-be-done-by-*this*-time I/O) or
CONFIG_IOSCHED_CFQ (which endeavours to give everyone using the disks a
fair share of time).
-- `End users are just test loads for verifying that the system works, kind of like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s
- Next message: phil-news-nospam_at_ipal.net: "Re: efficacy of Linux w/o swap"
- Previous message: James McIninch: "Re: efficacy of Linux w/o swap"
- In reply to: phil-news-nospam_at_ipal.net: "efficacy of Linux w/o swap"
- Next in thread: phil-news-nospam_at_ipal.net: "Re: efficacy of Linux w/o swap"
- Reply: phil-news-nospam_at_ipal.net: "Re: efficacy of Linux w/o swap"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|