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
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
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
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
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
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,
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,
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
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
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);
>
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);
schedule
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
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:
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
_should_
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, and we might
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, as long as
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 __GFP_
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 __GFP_WAIT? It's true
20 matches
Mail list logo
