Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1383461
| 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 |
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
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