All of lore.kernel.org
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH 2/2] sysvshm: SHM_LOCK use lru_add_drain_all_async()
Date: Tue, 03 Jan 2012 21:19:01 -0500	[thread overview]
Message-ID: <4F03B715.4080005@gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1201031724300.1254@eggly.anvils>

(1/3/12 8:51 PM), Hugh Dickins wrote:
> On Sun, 1 Jan 2012, kosaki.motohiro@gmail.com wrote:
>> From: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>>
>> shmctl also don't need synchrounous pagevec drain. This patch replace it with
>> lru_add_drain_all_async().
>>
>> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>
> Let me answer this 2/2 first since it's easier.
>
> I'm going to thank you for bringing this lru_add_drain_all()
> to my attention, I had not noticed it; but Nak the patch itself.
>
> The reason being, that particular lru_add_drain_all() serves no
> useful purpose, so let's delete it instead of replacing it.  I believe
> that it serves no purpose for SHM_LOCK and no purpose for SHM_UNLOCK.
>
> I'm dabbling in this area myself, since you so cogently pointed out that
> I'd tried to add a cond_resched() to scan_mapping_unevictable_pages()
> (which is a helper for SHM_UNLOCK here) while it's under spinlock.
>
> In testing my fix for that, I find that there has been no attempt to
> keep the Unevictable count accurate on SysVShm: SHM_LOCK pages get
> marked unevictable lazily later as memory pressure discovers them -
> which perhaps mirrors the way in which SHM_LOCK makes no attempt to
> instantiate pages, unlike mlock.

Ugh, you are right. I'm recovering my remember gradually. Lee 
implemented immediate lru off logic at first and I killed it
to close a race. I completely forgot. So, yes, now SHM_LOCK has no 
attempt to instantiate pages. I'm ashamed.


>
> Since nobody has complained about that in the two years since we've
> had an Unevictable count in /proc/meminfo, I don't see any need to
> add code (it would need more than just your change here; would need
> more even than calling scan_mapping_unevictable_pages() at SHM_LOCK
> time - though perhaps along with your 1/2 that could handle it) and
> overhead to satisfy a need that nobody has.
>
> I'll delete that lru_add_drain_all() in my patch, okay?

Sure thing. :)


> (But in writing this, realize I still don't quite understand why
> the Unevictable count takes a second or two to get back to 0 after
> SHM_UNLOCK: perhaps I've more to discover.)

Interesting. I'm looking at this too.

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Hugh Dickins <hughd@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH 2/2] sysvshm: SHM_LOCK use lru_add_drain_all_async()
Date: Tue, 03 Jan 2012 21:19:01 -0500	[thread overview]
Message-ID: <4F03B715.4080005@gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1201031724300.1254@eggly.anvils>

(1/3/12 8:51 PM), Hugh Dickins wrote:
> On Sun, 1 Jan 2012, kosaki.motohiro@gmail.com wrote:
>> From: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>>
>> shmctl also don't need synchrounous pagevec drain. This patch replace it with
>> lru_add_drain_all_async().
>>
>> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>
>
> Let me answer this 2/2 first since it's easier.
>
> I'm going to thank you for bringing this lru_add_drain_all()
> to my attention, I had not noticed it; but Nak the patch itself.
>
> The reason being, that particular lru_add_drain_all() serves no
> useful purpose, so let's delete it instead of replacing it.  I believe
> that it serves no purpose for SHM_LOCK and no purpose for SHM_UNLOCK.
>
> I'm dabbling in this area myself, since you so cogently pointed out that
> I'd tried to add a cond_resched() to scan_mapping_unevictable_pages()
> (which is a helper for SHM_UNLOCK here) while it's under spinlock.
>
> In testing my fix for that, I find that there has been no attempt to
> keep the Unevictable count accurate on SysVShm: SHM_LOCK pages get
> marked unevictable lazily later as memory pressure discovers them -
> which perhaps mirrors the way in which SHM_LOCK makes no attempt to
> instantiate pages, unlike mlock.

Ugh, you are right. I'm recovering my remember gradually. Lee 
implemented immediate lru off logic at first and I killed it
to close a race. I completely forgot. So, yes, now SHM_LOCK has no 
attempt to instantiate pages. I'm ashamed.


>
> Since nobody has complained about that in the two years since we've
> had an Unevictable count in /proc/meminfo, I don't see any need to
> add code (it would need more than just your change here; would need
> more even than calling scan_mapping_unevictable_pages() at SHM_LOCK
> time - though perhaps along with your 1/2 that could handle it) and
> overhead to satisfy a need that nobody has.
>
> I'll delete that lru_add_drain_all() in my patch, okay?

Sure thing. :)


> (But in writing this, realize I still don't quite understand why
> the Unevictable count takes a second or two to get back to 0 after
> SHM_UNLOCK: perhaps I've more to discover.)

Interesting. I'm looking at this too.


  reply	other threads:[~2012-01-04  2:19 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-30  6:36 [PATCH] mm: do not drain pagevecs for mlock Tao Ma
2011-12-30  6:36 ` Tao Ma
2011-12-30  8:11 ` KOSAKI Motohiro
2011-12-30  8:11   ` KOSAKI Motohiro
2011-12-30  8:48   ` Tao Ma
2011-12-30  9:31     ` KOSAKI Motohiro
2011-12-30  9:31       ` KOSAKI Motohiro
2011-12-30  9:45       ` Tao Ma
2011-12-30  9:45         ` Tao Ma
2011-12-30 10:07         ` KOSAKI Motohiro
2011-12-30 10:07           ` KOSAKI Motohiro
2012-01-01  7:30           ` [PATCH 1/2] mm,mlock: drain pagevecs asynchronously kosaki.motohiro
2012-01-01  7:30             ` kosaki.motohiro
2012-01-04  1:17             ` Minchan Kim
2012-01-04  1:17               ` Minchan Kim
2012-01-04  2:38               ` KOSAKI Motohiro
2012-01-04  2:38                 ` KOSAKI Motohiro
2012-01-10  8:53                 ` Tao Ma
2012-01-10  8:53                   ` Tao Ma
2012-01-04  2:56             ` Hugh Dickins
2012-01-04  2:56               ` Hugh Dickins
2012-01-04 22:05             ` Andrew Morton
2012-01-04 22:05               ` Andrew Morton
2012-01-04 23:33               ` KOSAKI Motohiro
2012-01-04 23:33                 ` KOSAKI Motohiro
2012-01-05  0:19                 ` Hugh Dickins
2012-01-05  0:19                   ` Hugh Dickins
2012-01-01  7:30           ` [PATCH 2/2] sysvshm: SHM_LOCK use lru_add_drain_all_async() kosaki.motohiro
2012-01-01  7:30             ` kosaki.motohiro
2012-01-04  1:51             ` Hugh Dickins
2012-01-04  1:51               ` Hugh Dickins
2012-01-04  2:19               ` KOSAKI Motohiro [this message]
2012-01-04  2:19                 ` KOSAKI Motohiro
2012-01-04  5:17                 ` Hugh Dickins
2012-01-04  5:17                   ` Hugh Dickins
2012-01-04  8:34                   ` KOSAKI Motohiro
2012-01-04  8:34                     ` KOSAKI Motohiro
2012-01-06  6:13           ` [PATCH] mm: do not drain pagevecs for mlock Tao Ma
2012-01-06  6:13             ` Tao Ma
2012-01-06  6:18             ` KOSAKI Motohiro
2012-01-06  6:18               ` KOSAKI Motohiro
2012-01-06  6:30               ` Tao Ma
2012-01-06  6:30                 ` Tao Ma
2012-01-06  6:33                 ` KOSAKI Motohiro
2012-01-06  6:33                   ` KOSAKI Motohiro
2012-01-06  6:46                   ` Tao Ma
2012-01-06  6:46                     ` Tao Ma
2012-01-09 23:58                     ` KOSAKI Motohiro
2012-01-09 23:58                       ` KOSAKI Motohiro
2012-01-10  2:08                       ` Tao Ma
2012-01-10  2:08                         ` Tao Ma
2012-01-09  7:25           ` Tao Ma
2012-01-09  7:25             ` Tao Ma
2011-12-30 10:14         ` KOSAKI Motohiro
2011-12-30 10:14           ` KOSAKI Motohiro

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=4F03B715.4080005@gmail.com \
    --to=kosaki.motohiro@gmail.com \
    --cc=hughd@google.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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.