Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless
update of refcount
[Posted September 11, 2013 by corbet]
| From: |
| Ramkumar Ramachandra <artagnon-AT-gmail.com> |
| To: |
| Linus Torvalds <torvalds-AT-linux-foundation.org> |
| Subject: |
| Re: [PATCH v7 1/4] spinlock: A new lockref structure for lockless update of refcount |
| Date: |
| Mon, 9 Sep 2013 09:36:39 +0530 |
| Message-ID: |
| <CALkWK0mLU+N6NEwrcx9KJyv1RdU4=7UXbR3MAitSmxkredj7rQ@mail.gmail.com> |
| Cc: |
| Al Viro <viro-AT-zeniv.linux.org.uk>, Ingo Molnar <mingo-AT-kernel.org>, Benjamin Herrenschmidt <benh-AT-kernel.crashing.org>, Waiman Long <Waiman.Long-AT-hp.com>, Jeff Layton <jlayton-AT-redhat.com>, Miklos Szeredi <mszeredi-AT-suse.cz>, Ingo Molnar <mingo-AT-redhat.com>, Thomas Gleixner <tglx-AT-linutronix.de>, linux-fsdevel <linux-fsdevel-AT-vger.kernel.org>, Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>, Peter Zijlstra <peterz-AT-infradead.org>, Steven Rostedt <rostedt-AT-goodmis.org>, Andi Kleen <andi-AT-firstfloor.org>, "Chandramouleeswaran, Aswin" <aswin-AT-hp.com>, "Norton, Scott J" <scott.norton-AT-hp.com> |
| Archive‑link: | |
Article |
Linus Torvalds wrote:
> On Sun, Sep 8, 2013 at 5:03 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>>
>> There's one exception - basically, we decide to put duplicates of
>> reference(s) we hold into (a bunch of) structures being created. If
>> we decide that we'd failed and need to roll back, the structures
>> need to be taken out of whatever lists, etc. they'd been already
>> put on and references held in them - dropped. That removal gets done
>> under a spinlock. Sure, we can string those structures on some kind
>> of temp list, drop the spinlock and do dput() on everything in there,
>> but it's much more convenient to just free them as we are evicting
>> them, doing dput() as we go. Which is safe, since we are still have
>> the references used to create these buggers pinned down.
Dropping the spinlocks means more cores; unfortunately, a quad-core
seems to be the limit. Users must divide their time between reading
history and contributing to the present: some amount of persistent
data is a must on every user's machine. Pixel seems to be heading in
the wrong direction: that's what is stressing us out.
Ram
--
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/
