Alan Cox wrote:
Files are different. File content tends to be grouped
in large related chunks, both logically in the file and
on disk. Generally there is a lot more file data on a
system than what fits in memory.
Binary paging patterns don't always look like that unfortunately although
I susp
Rik van Riel wrote:
> Al Boldi wrote:
> > Good idea, but unless we understand the problems involved, we are bound
> > to repeat it. So my first question would be: Why is swap-in so slow?
> >
> > As I have posted in other threads, swap-in of consecutive pages suffers
> > a 2x slowdown wrt swap-out
> Files are different. File content tends to be grouped
> in large related chunks, both logically in the file and
> on disk. Generally there is a lot more file data on a
> system than what fits in memory.
Binary paging patterns don't always look like that unfortunately although
I suspect we migh
Al Boldi wrote:
Chris Snook wrote:
At best, reads can be read-ahead and cached, which is why
sequential swap-in sucks less. On-demand reads are as expensive as I/O
can get.
Which means that it should be at least as fast as swap-out, even faster
because write to disk is usually slower than
Al Boldi wrote:
Good idea, but unless we understand the problems involved, we are bound to
repeat it. So my first question would be: Why is swap-in so slow?
As I have posted in other threads, swap-in of consecutive pages suffers a 2x
slowdown wrt swap-out, whereas swap-in of random pages su
Al Boldi wrote:
Chris Snook wrote:
Al Boldi wrote:
Because it is hard to quantify the expected swap-in speed for random
pages, let's first tackle the swap-in of consecutive pages, which should
be at least as fast as swap-out. So again, why is swap-in so slow?
If I'm writing 20 pages to swap,
Chris Snook wrote:
> Al Boldi wrote:
> > Because it is hard to quantify the expected swap-in speed for random
> > pages, let's first tackle the swap-in of consecutive pages, which should
> > be at least as fast as swap-out. So again, why is swap-in so slow?
>
> If I'm writing 20 pages to swap, I c
Al Boldi wrote:
Chris Snook wrote:
Resource size has been outpacing processing latency since the dawn of
time. Disks get bigger much faster than seek times shrink. Main memory
and cache keep growing, while single-threaded processing speed has nearly
ground to a halt.
In the old days, it made l
Chris Snook wrote:
> Resource size has been outpacing processing latency since the dawn of
> time. Disks get bigger much faster than seek times shrink. Main memory
> and cache keep growing, while single-threaded processing speed has nearly
> ground to a halt.
>
> In the old days, it made lots of s
9 matches
Mail list logo
