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:
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
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
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
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 can find
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,
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
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
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 sense
10 matches
Mail list logo
