On Sat, 9 Jun 2001, Rik van Riel wrote:
> On 5 Jun 2001, Zlatko Calusic wrote:
> > Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> >
> > [snip]
> > > Exactly. And when we reach a low watermark of memory, we start writting
> > > out the anonymous memory.
> >
> > Hm, my observations are a little bit
On 5 Jun 2001, Zlatko Calusic wrote:
> Marcelo Tosatti <[EMAIL PROTECTED]> writes:
>
> [snip]
> > Exactly. And when we reach a low watermark of memory, we start writting
> > out the anonymous memory.
>
> Hm, my observations are a little bit different. I find that writeouts
> happen sooner than
On 5 Jun 2001, Zlatko Calusic wrote:
Marcelo Tosatti [EMAIL PROTECTED] writes:
[snip]
Exactly. And when we reach a low watermark of memory, we start writting
out the anonymous memory.
Hm, my observations are a little bit different. I find that writeouts
happen sooner than the moment
On Sat, 9 Jun 2001, Rik van Riel wrote:
On 5 Jun 2001, Zlatko Calusic wrote:
Marcelo Tosatti [EMAIL PROTECTED] writes:
[snip]
Exactly. And when we reach a low watermark of memory, we start writting
out the anonymous memory.
Hm, my observations are a little bit different. I find
On Tue, 5 Jun 2001, Mike Galbraith wrote:
> Yes. If we start writing out sooner, we aren't stuck with pushing a
> ton of IO all at once and can use prudent limits. Not only because of
> potential allocation problems, but because our situation is changing
> rapidly so small corrections done
Ed Tomlinson <[EMAIL PROTECTED]> writes:
[snip]
> Maybe we can have the best of both worlds. Is it possible to allocate the BH
> early and then defer the IO? The idea being to make IO possible without having
> to allocate. This would let us remove the async page limit but would ensure
> we
Mike Galbraith <[EMAIL PROTECTED]> writes:
> On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
>
> > Zlatko,
> >
> > I've read your patch to remove nr_async_pages limit while reading an
> > archive on the web. (I have to figure out why lkml is not being delivered
> > correctly to me...)
> >
> >
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
[snip]
> Exactly. And when we reach a low watermark of memory, we start writting
> out the anonymous memory.
>
Hm, my observations are a little bit different. I find that writeouts
happen sooner than the moment we reach low watermark, and many times
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> Zlatko,
>
> I've read your patch to remove nr_async_pages limit while reading an
> archive on the web. (I have to figure out why lkml is not being delivered
> correctly to me...)
>
> Quoting your message:
>
> "That artificial limit hurts both
Hi,
To paraphase Mike,
We defer doing IO until we are under short of storage. Doing IO uses storage.
So delaying IO as much as we do forces us to impose limits. If we did the IO
earlier we would not need this limit often, if at all.
Does this make any sense?
Maybe we can have the best of
On Tue, 5 Jun 2001, Marcelo Tosatti wrote:
> On Tue, 5 Jun 2001, Mike Galbraith wrote:
>
> > On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
> >
> > > Zlatko,
> > >
> > > I've read your patch to remove nr_async_pages limit while reading an
> > > archive on the web. (I have to figure out why lkml is
On Tue, 5 Jun 2001, Mike Galbraith wrote:
> On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
>
> > Zlatko,
> >
> > I've read your patch to remove nr_async_pages limit while reading an
> > archive on the web. (I have to figure out why lkml is not being delivered
> > correctly to me...)
> >
> >
On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
> Zlatko,
>
> I've read your patch to remove nr_async_pages limit while reading an
> archive on the web. (I have to figure out why lkml is not being delivered
> correctly to me...)
>
> Quoting your message:
>
> "That artificial limit hurts both swap out
On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
Zlatko,
I've read your patch to remove nr_async_pages limit while reading an
archive on the web. (I have to figure out why lkml is not being delivered
correctly to me...)
Quoting your message:
That artificial limit hurts both swap out and swap
On Tue, 5 Jun 2001, Mike Galbraith wrote:
On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
Zlatko,
I've read your patch to remove nr_async_pages limit while reading an
archive on the web. (I have to figure out why lkml is not being delivered
correctly to me...)
Quoting your message:
On Tue, 5 Jun 2001, Marcelo Tosatti wrote:
On Tue, 5 Jun 2001, Mike Galbraith wrote:
On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
Zlatko,
I've read your patch to remove nr_async_pages limit while reading an
archive on the web. (I have to figure out why lkml is not being delivered
Hi,
To paraphase Mike,
We defer doing IO until we are under short of storage. Doing IO uses storage.
So delaying IO as much as we do forces us to impose limits. If we did the IO
earlier we would not need this limit often, if at all.
Does this make any sense?
Maybe we can have the best of
Marcelo Tosatti [EMAIL PROTECTED] writes:
Zlatko,
I've read your patch to remove nr_async_pages limit while reading an
archive on the web. (I have to figure out why lkml is not being delivered
correctly to me...)
Quoting your message:
That artificial limit hurts both swap out and
Ed Tomlinson [EMAIL PROTECTED] writes:
[snip]
Maybe we can have the best of both worlds. Is it possible to allocate the BH
early and then defer the IO? The idea being to make IO possible without having
to allocate. This would let us remove the async page limit but would ensure
we could
Mike Galbraith [EMAIL PROTECTED] writes:
On Mon, 4 Jun 2001, Marcelo Tosatti wrote:
Zlatko,
I've read your patch to remove nr_async_pages limit while reading an
archive on the web. (I have to figure out why lkml is not being delivered
correctly to me...)
Quoting your message:
Marcelo Tosatti [EMAIL PROTECTED] writes:
[snip]
Exactly. And when we reach a low watermark of memory, we start writting
out the anonymous memory.
Hm, my observations are a little bit different. I find that writeouts
happen sooner than the moment we reach low watermark, and many times
just
On Tue, 5 Jun 2001, Mike Galbraith wrote:
Yes. If we start writing out sooner, we aren't stuck with pushing a
ton of IO all at once and can use prudent limits. Not only because of
potential allocation problems, but because our situation is changing
rapidly so small corrections done often
22 matches
Mail list logo
