Messages in this thread | | | Date | Thu, 27 Apr 2006 13:33:54 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH 1/2] mm: serialize OOM kill operations |
| |
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |