Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1383461

Re: preempt_count overflow in CONFIG_PREEMPT

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: preempt_count overflow in CONFIG_PREEMPT
Date 2016-04-20 16:50 +0200
Message-ID <rq1C2-Zj-25@gated-at.bofh.it> (permalink)
References <rpxNE-2xF-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Apr 19, 2016 at 03:58:43PM +0900, Minchan Kim wrote:
> migration trial A page to B page.
> B is newly allocated page so it's empty.
> 
> 1. freeze every objects in A page
>    for object in a page
>        bit_spin_lock(object)
>       
> 2. memcpy(B, A, PAGE_SIZE);
> 
> 3. unfreeze every objects in A page
>    for object in a page
>        bit_spin_unlock(object)
> 
> 4. put_page(A);
> 
> The logic is rather staightforward, I guess. :)
> Here, the problem is that unlike object migration, page migration
> needs to prevent all objects access in a page all at once before step 2.
> So, if we are luck, we can increase preempt_count as 113 every CPU so
> easily preempt_count_add emits spinlock count overflow in
> DEBUG_LOCKS_WARN_ON if we are multiple CPUs.(My machine is 12 CPU).
> 
> I think there are several choices to fix it but I'm not sure what's
> the best so I want to hear your opinion.
> 
> 1. increase preempt_count size?

Nope, 256 is way far too many locks to be holding, esp. spin-locks. You
get the most horrid latency spikes from that.

> 2. support bit_spin_lock_no_preempt/bit_spin_unlock_no_preempt?

Only if you really really really have to, but it would suck.

> 3. redesign zsmalloc page migration locking granularity?
> 
> I want to avoid 3 if possible because such design will make code
> very complicated and may hurt scalabitity and performance, I guess.

This really is your best option. You don't think O(nr_cpus) locking is a
scalability fail?

> I guess 8bit for PREEMPT_BITS is too small for considering the
> number of CPUs in recent computer system?

Not really. Holding a lock (or even multiple as you do) for each cpu is
a completely painful thing and doesn't scale.

> I hope I'm not alone to see this issue until now. :)

Very occasionally people run into this.. we try and convince them to
change their ways.

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

preempt_count overflow in CONFIG_PREEMPT Minchan Kim <minchan@kernel.org> - 2016-04-19 09:00 +0200
  Re: preempt_count overflow in CONFIG_PREEMPT Peter Zijlstra <peterz@infradead.org> - 2016-04-20 16:50 +0200

csiph-web