On 12/14/2013 06:09 AM, Linus Torvalds wrote:
On Wed, Dec 11, 2013 at 3:05 PM, Andrew Morton
wrote:
But I'm really struggling to think up an implementation! The current
code looks only at the caller's node and doesn't seem to make much
sense. Should we look at all nodes? Hard to say
On 12/14/2013 06:09 AM, Linus Torvalds wrote:
On Wed, Dec 11, 2013 at 3:05 PM, Andrew Morton
a...@linux-foundation.org wrote:
But I'm really struggling to think up an implementation! The current
code looks only at the caller's node and doesn't seem to make much
sense. Should we look at all
On Wed, Dec 11, 2013 at 3:05 PM, Andrew Morton
wrote:
>
> But I'm really struggling to think up an implementation! The current
> code looks only at the caller's node and doesn't seem to make much
> sense. Should we look at all nodes? Hard to say without prior
> knowledge of where those pages
On Wed, Dec 11, 2013 at 3:05 PM, Andrew Morton
a...@linux-foundation.org wrote:
But I'm really struggling to think up an implementation! The current
code looks only at the caller's node and doesn't seem to make much
sense. Should we look at all nodes? Hard to say without prior
knowledge of
On Wed 11-12-13 15:05:22, Andrew Morton wrote:
> On Wed, 11 Dec 2013 23:49:17 +0100 Jan Kara wrote:
>
> > > /*
> > > - * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a
> > > - * sensible upper limit.
> > > + * max_sane_readahead() is disabled. It can later be removed
> >
On Wed 11-12-13 15:05:22, Andrew Morton wrote:
On Wed, 11 Dec 2013 23:49:17 +0100 Jan Kara j...@suse.cz wrote:
/*
- * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a
- * sensible upper limit.
+ * max_sane_readahead() is disabled. It can later be removed
On Wed, 11 Dec 2013 23:49:17 +0100 Jan Kara wrote:
> > /*
> > - * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a
> > - * sensible upper limit.
> > + * max_sane_readahead() is disabled. It can later be removed altogether,
> > but
> > + * let's keep a skeleton in place for
On Wed 04-12-13 13:48:38, Andrew Morton wrote:
> On Wed, 04 Dec 2013 14:38:11 +0530 Raghavendra K T
> wrote:
>
> > On 12/04/2013 02:11 PM, Andrew Morton wrote:
> > > On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T
> > > wrote:
> > >
> > >> Unfaortunately, from my search, I saw that the
On Wed 04-12-13 13:48:38, Andrew Morton wrote:
On Wed, 04 Dec 2013 14:38:11 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
On 12/04/2013 02:11 PM, Andrew Morton wrote:
On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
On Wed, 11 Dec 2013 23:49:17 +0100 Jan Kara j...@suse.cz wrote:
/*
- * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a
- * sensible upper limit.
+ * max_sane_readahead() is disabled. It can later be removed altogether,
but
+ * let's keep a skeleton in place for
On 12/05/2013 03:18 AM, Andrew Morton wrote:
On Wed, 04 Dec 2013 14:38:11 +0530 Raghavendra K T
wrote:
On 12/04/2013 02:11 PM, Andrew Morton wrote:
:
: This patch takes it all out and applies the same upper limit as is used in
: sys_readahead() - half the inactive list.
:
: +/*
: +
On Wed, 04 Dec 2013 14:38:11 +0530 Raghavendra K T
wrote:
> On 12/04/2013 02:11 PM, Andrew Morton wrote:
> > On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T
> > wrote:
> >
> >> Unfaortunately, from my search, I saw that the code belonged to pre git
> >> time, so could not get much
On 12/04/2013 02:11 PM, Andrew Morton wrote:
On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T
wrote:
Unfaortunately, from my search, I saw that the code belonged to pre git
time, so could not get much information on that.
Here: https://lkml.org/lkml/2004/8/20/242
It seems it was done as
On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T
wrote:
> > I don't recall the rationale for the current code and of course we
> > didn't document it. It might be in the changelogs somewhere - could
> > you please do the git digging and see if you can find out?
>
> Unfaortunately, from my
Thank you Andrew.
On 12/04/2013 04:08 AM, Andrew Morton wrote:
On Tue, 3 Dec 2013 16:06:17 +0530 Raghavendra K T
wrote:
On a cpu with an empty numa node,
This makes no sense - numa nodes don't reside on CPUs.
I think you mean "on a CPU which resides on a memoryless NUMA node"?
You
Thank you Andrew.
On 12/04/2013 04:08 AM, Andrew Morton wrote:
On Tue, 3 Dec 2013 16:06:17 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
On a cpu with an empty numa node,
This makes no sense - numa nodes don't reside on CPUs.
I think you mean on a CPU which resides on a
On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
I don't recall the rationale for the current code and of course we
didn't document it. It might be in the changelogs somewhere - could
you please do the git digging and see if you can find out?
On 12/04/2013 02:11 PM, Andrew Morton wrote:
On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
Unfaortunately, from my search, I saw that the code belonged to pre git
time, so could not get much information on that.
Here:
On Wed, 04 Dec 2013 14:38:11 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
On 12/04/2013 02:11 PM, Andrew Morton wrote:
On Wed, 04 Dec 2013 14:00:09 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
Unfaortunately, from my search, I saw that the code
On 12/05/2013 03:18 AM, Andrew Morton wrote:
On Wed, 04 Dec 2013 14:38:11 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
On 12/04/2013 02:11 PM, Andrew Morton wrote:
:
: This patch takes it all out and applies the same upper limit as is used in
: sys_readahead() -
On Tue, 3 Dec 2013 16:06:17 +0530 Raghavendra K T
wrote:
> On a cpu with an empty numa node,
This makes no sense - numa nodes don't reside on CPUs.
I think you mean "on a CPU which resides on a memoryless NUMA node"?
> readahead fails because max_sane_readahead
> returns zero. The reason is
On a cpu with an empty numa node, readahead fails because max_sane_readahead
returns zero. The reason is we look into number of inactive + free pages
available on the current node.
The following patch tries to fix the behaviour by checking for potential
empty numa node cases.
The rationale for
On a cpu with an empty numa node, readahead fails because max_sane_readahead
returns zero. The reason is we look into number of inactive + free pages
available on the current node.
The following patch tries to fix the behaviour by checking for potential
empty numa node cases.
The rationale for
On Tue, 3 Dec 2013 16:06:17 +0530 Raghavendra K T
raghavendra...@linux.vnet.ibm.com wrote:
On a cpu with an empty numa node,
This makes no sense - numa nodes don't reside on CPUs.
I think you mean on a CPU which resides on a memoryless NUMA node?
readahead fails because max_sane_readahead
24 matches
Mail list logo
