linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Dave Peterson <dsp@llnl.gov>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	riel@surriel.com, akpm@osdl.org
Subject: Re: [PATCH 1/2] mm: serialize OOM kill operations
Date: Thu, 27 Apr 2006 13:33:54 +1000	[thread overview]
Message-ID: <44503BA2.7000405@yahoo.com.au> (raw)
In-Reply-To: <200604261014.15008.dsp@llnl.gov>

Dave Peterson wrote:

>On Tuesday 25 April 2006 21:10, Nick Piggin wrote:
>
>>Firstly why not use a semaphore and trylocks instead of your homebrew
>>lock?
>>
>
>Are you suggesting something like this?
>
>	spinlock_t oom_kill_lock = SPIN_LOCK_UNLOCKED;
>
>	static inline int oom_kill_start(void)
>	{
>		return !spin_trylock(&oom_kill_lock);
>	}
>
>	static inline void oom_kill_finish()
>	{
>		spin_unlock(&oom_kill_lock);
>	}
>
>If you prefer the above implementation, I can rework the patch as
>above.
>

I think you need a semaphore? Either way, drop the trivial wrappers.

>
>>Second, can you arrange it without using the extra field in mm_struct
>>and operation in the mmput fast path?
>>
>
>I'm open to suggestions on other ways of implementing this.  However I
>think the performance impact of the proposed implementation should be
>miniscule.  The code added to mmput() executes only when the referece
>count has reached 0; not on every decrement of the reference count.
>Once the reference count has reached 0, the common-case behavior is
>still only testing a boolean flag followed by a not-taken branch.  The
>use of unlikely() should help the compiler and CPU branch prediction
>hardware minimize overhead in the typical case where oom_kill_finish()
>is not called.
>

Mainly the cost of increasing cacheline footprint. I think someone
suggested using a flag bit somewhere... that'd be preferable.

--

Send instant messages to your online friends http://au.messenger.yahoo.com 

--
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:[~2006-04-27  3:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-26  0:01 [PATCH 1/2] mm: serialize OOM kill operations Dave Peterson
2006-04-26  4:10 ` Nick Piggin
2006-04-26 17:14   ` Dave Peterson
2006-04-27  3:33     ` Nick Piggin [this message]
2006-04-27 16:56       ` Dave Peterson
2006-04-28  5:00         ` Nick Piggin
2006-04-28  5:05           ` Nick Piggin

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=44503BA2.7000405@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=dsp@llnl.gov \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@surriel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).