Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1330726 > unrolled thread
| Started by | Keith Busch <keith.busch@intel.com> |
|---|---|
| First post | 2016-02-10 00:00 +0100 |
| Last post | 2016-02-10 00:00 +0100 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Keith Busch <keith.busch@intel.com> - 2016-02-10 00:00 +0100
| From | Keith Busch <keith.busch@intel.com> |
|---|---|
| Date | 2016-02-10 00:00 +0100 |
| Subject | Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended |
| Message-ID | <r0pqi-251-25@gated-at.bofh.it> |
On Tue, Feb 09, 2016 at 11:22:04AM +0000, Wenbo Wang wrote: > In most cases, rcu read lock is just a preempt_disable, which is what get_cpu does. I don't see any risk. Yes, many rcu_read_lock cases expand similarly to get_cpu. What about the other cases? FWIW, I don't think we'll hit the problem with the proposed rcu sync. Heck, we don't even have a synchronize today and we don't hit the theoretical problem.
Back to top | Article view | linux.kernel
csiph-web