All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Fengguang Wu <fengguang.wu@intel.com>,
	David Cohen <david.a.cohen@linux.intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Damien Ramonda <damien.ramonda@intel.com>,
	Jan Kara <jack@suse.cz>, Linus <torvalds@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Date: Mon, 10 Feb 2014 13:51:42 +0530	[thread overview]
Message-ID: <52F88C16.70204@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402071239301.4212@chino.kir.corp.google.com>

On 02/08/2014 02:11 AM, David Rientjes wrote:
> On Fri, 7 Feb 2014, Raghavendra K T wrote:
>> 3) Change the "readahead into remote memory" part of the documentation
>> which is misleading.
>>
>> ( I feel no need to add numa_mem_id() since we would specifically limit
>> the readahead with MAX_REMOTE_READAHEAD in memoryless cpu cases).
>>
>
> I don't understand what you're saying, numa_mem_id() is local memory to
> current's cpu.  When a node consists only of cpus and not memory it is not
> true that all memory is then considered remote, you won't find that in any
> specification that defines memory affinity including the ACPI spec.  I can
> trivially define all cpus on my system to be on memoryless nodes and
> having that affect readahead behavior when, in fact, there is affinity
> would be ridiculous.
>
As you rightly pointed , I 'll drop remote memory term and use
something like  :

"* Ensure readahead success on a memoryless node cpu. But we limit
  * the readahead to 4k pages to avoid trashing page cache." ..

Regarding ACCESS_ONCE, since we will have to add
inside the function and still there is nothing that could prevent us
getting run on different cpu with a different node (as Andrew ponted), I 
have not included in current patch that I am posting.
Moreover this case is hopefully not fatal since it is just a hint for 
readahead we can do.

So there are many possible implementation:
(1) use numa_mem_id(), apply freepage limit  and use 4k page limit for 
all case
(Jan had reservation about this case)

(2)for normal case:    use free memory calculation and do not apply 4k
     limit (no change).
    for memoryless cpu case:  use numa_mem_id for more accurate
     calculation of limit and also apply 4k limit.

(3) for normal case:   use free memory calculation and do not apply 4k
     limit (no change).
     for memoryless case: apply 4k page limit

(4) use numa_mem_id() and apply only free page limit..

So, I ll be resending the patch with changelog and comment changes
based on your and Andrew's feedback (type (3) implementation).





WARNING: multiple messages have this Message-ID (diff)
From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Fengguang Wu <fengguang.wu@intel.com>,
	David Cohen <david.a.cohen@linux.intel.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Damien Ramonda <damien.ramonda@intel.com>,
	Jan Kara <jack@suse.cz>, Linus <torvalds@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages
Date: Mon, 10 Feb 2014 13:51:42 +0530	[thread overview]
Message-ID: <52F88C16.70204@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402071239301.4212@chino.kir.corp.google.com>

On 02/08/2014 02:11 AM, David Rientjes wrote:
> On Fri, 7 Feb 2014, Raghavendra K T wrote:
>> 3) Change the "readahead into remote memory" part of the documentation
>> which is misleading.
>>
>> ( I feel no need to add numa_mem_id() since we would specifically limit
>> the readahead with MAX_REMOTE_READAHEAD in memoryless cpu cases).
>>
>
> I don't understand what you're saying, numa_mem_id() is local memory to
> current's cpu.  When a node consists only of cpus and not memory it is not
> true that all memory is then considered remote, you won't find that in any
> specification that defines memory affinity including the ACPI spec.  I can
> trivially define all cpus on my system to be on memoryless nodes and
> having that affect readahead behavior when, in fact, there is affinity
> would be ridiculous.
>
As you rightly pointed , I 'll drop remote memory term and use
something like  :

"* Ensure readahead success on a memoryless node cpu. But we limit
  * the readahead to 4k pages to avoid trashing page cache." ..

Regarding ACCESS_ONCE, since we will have to add
inside the function and still there is nothing that could prevent us
getting run on different cpu with a different node (as Andrew ponted), I 
have not included in current patch that I am posting.
Moreover this case is hopefully not fatal since it is just a hint for 
readahead we can do.

So there are many possible implementation:
(1) use numa_mem_id(), apply freepage limit  and use 4k page limit for 
all case
(Jan had reservation about this case)

(2)for normal case:    use free memory calculation and do not apply 4k
     limit (no change).
    for memoryless cpu case:  use numa_mem_id for more accurate
     calculation of limit and also apply 4k limit.

(3) for normal case:   use free memory calculation and do not apply 4k
     limit (no change).
     for memoryless case: apply 4k page limit

(4) use numa_mem_id() and apply only free page limit..

So, I ll be resending the patch with changelog and comment changes
based on your and Andrew's feedback (type (3) implementation).




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-02-10  8:15 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-22 10:53 [RFC PATCH V5] mm readahead: Fix readahead fail for no local memory and limit readahead pages Raghavendra K T
2014-01-22 10:53 ` Raghavendra K T
2014-02-03  8:30 ` Raghavendra K T
2014-02-03  8:30   ` Raghavendra K T
2014-02-06 22:51 ` Andrew Morton
2014-02-06 22:51   ` Andrew Morton
2014-02-06 22:58   ` David Rientjes
2014-02-06 22:58     ` David Rientjes
2014-02-06 23:22     ` Andrew Morton
2014-02-06 23:22       ` Andrew Morton
2014-02-06 23:48       ` David Rientjes
2014-02-06 23:48         ` David Rientjes
2014-02-06 23:58         ` David Rientjes
2014-02-06 23:58           ` David Rientjes
2014-02-07 10:42           ` Raghavendra K T
2014-02-07 10:42             ` Raghavendra K T
2014-02-07 20:41             ` David Rientjes
2014-02-07 20:41               ` David Rientjes
2014-02-10  8:21               ` Raghavendra K T [this message]
2014-02-10  8:21                 ` Raghavendra K T
2014-02-10 10:05                 ` David Rientjes
2014-02-10 10:05                   ` David Rientjes
2014-02-10 12:25                   ` Raghavendra K T
2014-02-10 12:25                     ` Raghavendra K T
2014-02-10 21:35                     ` David Rientjes
2014-02-10 21:35                       ` David Rientjes
2014-02-13  7:07                       ` Raghavendra K T
2014-02-13  7:07                         ` Raghavendra K T
2014-02-13  8:05                         ` David Rientjes
2014-02-13  8:05                           ` David Rientjes
2014-02-13 10:04                           ` Raghavendra K T
2014-02-13 10:04                             ` Raghavendra K T
2014-02-13 22:41                             ` David Rientjes
2014-02-13 22:41                               ` David Rientjes
2014-02-14  0:14                               ` Nishanth Aravamudan
2014-02-14  0:14                                 ` Nishanth Aravamudan
2014-02-14  0:37                                 ` Linus Torvalds
2014-02-14  0:37                                   ` Linus Torvalds
2014-02-14  0:45                                   ` Andrew Morton
2014-02-14  0:45                                     ` Andrew Morton
2014-02-14  4:32                                   ` Nishanth Aravamudan
2014-02-14  4:32                                     ` Nishanth Aravamudan
2014-02-14 10:54                                     ` David Rientjes
2014-02-14 10:54                                       ` David Rientjes
2014-02-17 19:28                                       ` Nishanth Aravamudan
2014-02-17 19:28                                         ` Nishanth Aravamudan
2014-02-17 23:14                                         ` David Rientjes
2014-02-17 23:14                                           ` David Rientjes
2014-02-18  1:31                                           ` Nishanth Aravamudan
2014-02-18  1:31                                             ` Nishanth Aravamudan
2014-02-17 22:59                                     ` Linus Torvalds
2014-02-17 22:59                                       ` Linus Torvalds
2014-02-14  7:43                                   ` Jan Kara
2014-02-14  7:43                                     ` Jan Kara
2014-02-17 22:57                                     ` Linus Torvalds
2014-02-17 22:57                                       ` Linus Torvalds
2014-02-14  5:47                               ` Nishanth Aravamudan
2014-02-14  5:47                                 ` Nishanth Aravamudan
2014-02-13 21:06                           ` Andrew Morton
2014-02-13 21:06                             ` Andrew Morton
2014-02-13 21:42                             ` Nishanth Aravamudan
2014-02-13 21:42                               ` Nishanth Aravamudan
2014-02-10  8:29   ` [RFC PATCH V5 RESEND] " Raghavendra K T
2014-02-10  8:29     ` Raghavendra K T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52F88C16.70204@linux.vnet.ibm.com \
    --to=raghavendra.kt@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=damien.ramonda@intel.com \
    --cc=david.a.cohen@linux.intel.com \
    --cc=fengguang.wu@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.