lkml.org 
[lkml]   [2001]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: dynamic swap prioritizing
On Oct 12, 2001  02:45 +0200, Xuan Baldauf wrote:
> > I'd rather just have the statistic data in a regular file for ALL disks,
> > and then send it to the kernel via ioctl or write to a special file that
> > the kernel will read from. I don't think it is critical to have this
> > data right at boot time, since it would only be used for optimizing I/O
> > access and would not be required for a disk to actually work.
>
> why do you want to separate statistics data out? The statistics are not
> about disk throughput, head seek times, etc. They are just about the time
> between "needing a page" and "getting that page", which is very abstract.
> Let's call it the swapin-delay. It does not only depend on disk-throughput
> and head seek times, but also on "device business".

What I am saying is that such information is useful for ALL devices, and
not just swap devices. There was a long thread from Daniel Phillips
where he was working on (1) a few months ago. Why is this data useful?

1) You have dirty pages in RAM, when should you write them? The current
system is to delay the write as long as possible in case the dirty
pages are discarded (e.g. temp file) before they need to be written.
However, if the disk is idle during this time, then doing the write
immediately will not impose extra overhead, and will mean that the
dirty page could be freed quickly if there was a need for memory.
2) Swap or MD RAID 1 load balancing. Which device should you write to
(swap) or read from (RAID 1)? If you know how fast/busy each device
is, you can make a better decision on this instead of round-robin.
3) Guaranteed rate I/O. For XFS/XLV on SGI IRIX, you can request a
guaranteed I/O rate for a specific time period (e.g. to record video
or capture data from an experiment) and the system will tell you if
it is possible or not. In the IRIX case, they had data on each
drive to tell them what the performance is in advance, while Linux
would need to do a drive-by-drive benchmark instead.

A lot of the data needed for this is already part of "sard", but that
is only reporting the data to user space, while some of the above
decisions need to be done inside the kernel on a continuous basis.

Note that I'm NOT saying that having all of this data will improve
system performance (it may slow it down from overhead), but I was just
advocating a broader view of what could be done (and what has already
been done in related areas).

Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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