Hi,
The following patch changes two things:
- Counts asynchronous ll_rw_block() IO in the flushed pages counter (page_launder)
- Limits the amount of scanned pte's _by user tasks_ inside swap_out()
diff --exclude-from=/home/marcelo/exclude -Nur linux.orig/fs/buffer.c linux/fs/buffer.c
---
On Tue, Sep 26, 2000 at 10:12:44AM -0700, Linus Torvalds wrote:
> It should probably just be a GFP_USER (ie not the GFP_KERNEL "try very
> hard").
GFP_KERNEL and GFP_USER have to try equally very hard until the machine runs
_truly_ out of memory.
When the machine runs truly out of memory I think
On Tue, 26 Sep 2000, Arjan van de Ven wrote:
>
> And the network-stack in net/core/sock.c:sock_alloc_send_skb which sounds
> like a bug in this case, and might even be the cause of too many GFP_BUFFER
> allocations in loads suchs as Ingo's.
Hey, good grepping.
That looks like just complete bo
In article <[EMAIL PROTECTED]> you wrote:
> On Mon, 25 Sep 2000, Rik van Riel wrote:
>>
>> Hmmm, doesn't GFP_BUFFER simply imply that we cannot
>> allocate new buffer heads to do IO with??
> The name is a misnomer, partly due to historical reasons (the buffer cache
> used to be fragile, and if
Hi,
On Mon, Sep 25, 2000 at 09:17:54AM -0700, Linus Torvalds wrote:
>
> On Mon, 25 Sep 2000, Rik van Riel wrote:
> >
> > Hmmm, doesn't GFP_BUFFER simply imply that we cannot
> > allocate new buffer heads to do IO with??
>
> No.
>
> New buffer heads would be ok - recursion is fine in theory, a
On Mon, 25 Sep 2000, Linus Torvalds wrote:
> On Mon, 25 Sep 2000, Rik van Riel wrote:
> >
> > Hmmm, doesn't GFP_BUFFER simply imply that we cannot
> > allocate new buffer heads to do IO with??
>
> No.
>
> New buffer heads would be ok - recursion is fine in theory, as long as it
> is bounded, an
On Mon, 25 Sep 2000, Rik van Riel wrote:
>
> Hmmm, doesn't GFP_BUFFER simply imply that we cannot
> allocate new buffer heads to do IO with??
No.
New buffer heads would be ok - recursion is fine in theory, as long as it
is bounded, and we might bound it some other way (I don't think we
_shoul
On Mon, 25 Sep 2000, Ingo Molnar wrote:
>
> On Mon, 25 Sep 2000, Rik van Riel wrote:
>
> > 2) you are right, we /can/ schedule when __GFP_IO isn't set, this is
> >mistake ... now I'm getting confused about what __GFP_IO is all
> >about, does anybody know the _exact_ meaning of __GFP_IO ?
On Mon, 25 Sep 2000, Rik van Riel wrote:
> 2) you are right, we /can/ schedule when __GFP_IO isn't set, this is
>mistake ... now I'm getting confused about what __GFP_IO is all
>about, does anybody know the _exact_ meaning of __GFP_IO ?
__GFP_IO set to 1 means that the allocator can aff
On Sun, 24 Sep 2000, Ingo Molnar wrote:
> i'm wondering about the following piece of code in refill_inactive():
>
> if (current->need_resched && (gfp_mask & __GFP_IO)) {
> __set_current_state(TASK_RUNNING);
&g
i'm wondering about the following piece of code in refill_inactive():
if (current->need_resched && (gfp_mask & __GFP_IO)) {
__set_current_state(TASK_RUNNING);
schedule();
}
shouldnt this be _
11 matches
Mail list logo