From: Matthew Wilcox <willy@infradead.org> To: Dan Williams <dan.j.williams@intel.com> Cc: Seema Pandit <seema.pandit@intel.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, Boaz Harrosh <openosd@gmail.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, stable <stable@vger.kernel.org>, Robert Barror <robert.barror@intel.com>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Jan Kara <jack@suse.cz> Subject: Re: [PATCH] dax: Fix missed PMD wakeups Date: Fri, 5 Jul 2019 12:10:04 -0700 [thread overview] Message-ID: <20190705191004.GC32320@bombadil.infradead.org> (raw) In-Reply-To: <CAPcyv4gUiDw8Ma9mvbW5BamQtGZxWVuvBW7UrOLa2uijrXUWaw@mail.gmail.com> On Thu, Jul 04, 2019 at 04:27:14PM -0700, Dan Williams wrote: > On Thu, Jul 4, 2019 at 12:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > On Thu, Jul 04, 2019 at 06:54:50PM +0200, Jan Kara wrote: > > > On Wed 03-07-19 20:27:28, Matthew Wilcox wrote: > > > > So I think we're good for all current users. > > > > > > Agreed but it is an ugly trap. As I already said, I'd rather pay the > > > unnecessary cost of waiting for pte entry and have an easy to understand > > > interface. If we ever have a real world use case that would care for this > > > optimization, we will need to refactor functions to make this possible and > > > still keep the interfaces sane. For example get_unlocked_entry() could > > > return special "error code" indicating that there's no entry with matching > > > order in xarray but there's a conflict with it. That would be much less > > > error-prone interface. > > > > This is an internal interface. I think it's already a pretty gnarly > > interface to use by definition -- it's going to sleep and might return > > almost anything. There's not much scope for returning an error indicator > > either; value entries occupy half of the range (all odd numbers between 1 > > and ULONG_MAX inclusive), plus NULL. We could use an internal entry, but > > I don't think that makes the interface any easier to use than returning > > a locked entry. > > > > I think this iteration of the patch makes it a little clearer. What do you > > think? > > > > Not much clearer to me. get_unlocked_entry() is now misnamed and this misnamed? You'd rather it was called "try_get_unlocked_entry()"? > arrangement allows for mismatches of @order argument vs @xas > configuration. > Can you describe, or even better demonstrate with > numbers, why it's better to carry this complication than just > converging the waitqueues between the types? You've got the reproducer ;-) It seems quite wrong to make a page fault stall just because another task is working on a different page in the same 2MB chunk. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org> To: Dan Williams <dan.j.williams@intel.com> Cc: Jan Kara <jack@suse.cz>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Boaz Harrosh <openosd@gmail.com>, stable <stable@vger.kernel.org>, Robert Barror <robert.barror@intel.com>, Seema Pandit <seema.pandit@intel.com>, linux-nvdimm <linux-nvdimm@lists.01.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] dax: Fix missed PMD wakeups Date: Fri, 5 Jul 2019 12:10:04 -0700 [thread overview] Message-ID: <20190705191004.GC32320@bombadil.infradead.org> (raw) In-Reply-To: <CAPcyv4gUiDw8Ma9mvbW5BamQtGZxWVuvBW7UrOLa2uijrXUWaw@mail.gmail.com> On Thu, Jul 04, 2019 at 04:27:14PM -0700, Dan Williams wrote: > On Thu, Jul 4, 2019 at 12:14 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > On Thu, Jul 04, 2019 at 06:54:50PM +0200, Jan Kara wrote: > > > On Wed 03-07-19 20:27:28, Matthew Wilcox wrote: > > > > So I think we're good for all current users. > > > > > > Agreed but it is an ugly trap. As I already said, I'd rather pay the > > > unnecessary cost of waiting for pte entry and have an easy to understand > > > interface. If we ever have a real world use case that would care for this > > > optimization, we will need to refactor functions to make this possible and > > > still keep the interfaces sane. For example get_unlocked_entry() could > > > return special "error code" indicating that there's no entry with matching > > > order in xarray but there's a conflict with it. That would be much less > > > error-prone interface. > > > > This is an internal interface. I think it's already a pretty gnarly > > interface to use by definition -- it's going to sleep and might return > > almost anything. There's not much scope for returning an error indicator > > either; value entries occupy half of the range (all odd numbers between 1 > > and ULONG_MAX inclusive), plus NULL. We could use an internal entry, but > > I don't think that makes the interface any easier to use than returning > > a locked entry. > > > > I think this iteration of the patch makes it a little clearer. What do you > > think? > > > > Not much clearer to me. get_unlocked_entry() is now misnamed and this misnamed? You'd rather it was called "try_get_unlocked_entry()"? > arrangement allows for mismatches of @order argument vs @xas > configuration. > Can you describe, or even better demonstrate with > numbers, why it's better to carry this complication than just > converging the waitqueues between the types? You've got the reproducer ;-) It seems quite wrong to make a page fault stall just because another task is working on a different page in the same 2MB chunk.
next prev parent reply other threads:[~2019-07-05 19:10 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-03 7:24 [PATCH] dax: Fix missed PMD wakeups Dan Williams 2019-07-03 7:24 ` Dan Williams 2019-07-03 12:17 ` Matthew Wilcox 2019-07-03 12:17 ` Matthew Wilcox 2019-07-03 17:01 ` Dan Williams 2019-07-03 17:01 ` Dan Williams 2019-07-03 19:53 ` Matthew Wilcox 2019-07-03 19:53 ` Matthew Wilcox 2019-07-03 21:28 ` Dan Williams 2019-07-03 21:28 ` Dan Williams 2019-07-04 3:27 ` Matthew Wilcox 2019-07-04 3:27 ` Matthew Wilcox 2019-07-04 13:00 ` Boaz Harrosh 2019-07-04 13:00 ` Boaz Harrosh 2019-07-04 13:58 ` Matthew Wilcox 2019-07-04 13:58 ` Matthew Wilcox 2019-07-04 14:32 ` Boaz Harrosh 2019-07-04 14:32 ` Boaz Harrosh 2019-07-04 16:54 ` Jan Kara 2019-07-04 16:54 ` Jan Kara 2019-07-04 19:14 ` Matthew Wilcox 2019-07-04 19:14 ` Matthew Wilcox 2019-07-04 23:27 ` Dan Williams 2019-07-04 23:27 ` Dan Williams 2019-07-05 19:10 ` Matthew Wilcox [this message] 2019-07-05 19:10 ` Matthew Wilcox 2019-07-05 20:47 ` Dan Williams 2019-07-05 20:47 ` Dan Williams 2019-07-10 19:02 ` Jan Kara 2019-07-10 19:02 ` Jan Kara 2019-07-10 20:15 ` Matthew Wilcox 2019-07-10 20:15 ` Matthew Wilcox 2019-07-10 20:26 ` Jan Kara 2019-07-10 20:26 ` Jan Kara 2019-07-11 14:13 ` Matthew Wilcox 2019-07-11 14:13 ` Matthew Wilcox 2019-07-11 15:25 ` Matthew Wilcox 2019-07-11 15:25 ` Matthew Wilcox 2019-07-11 15:41 ` Jan Kara 2019-07-11 15:41 ` Jan Kara 2019-07-17 3:39 ` Dan Williams 2019-07-17 3:39 ` Dan Williams 2019-07-29 12:02 ` Jan Kara 2019-07-29 12:02 ` Jan Kara 2019-07-29 15:18 ` Dan Williams 2019-07-29 15:18 ` Dan Williams 2019-07-11 3:08 ` Matthew Wilcox 2019-07-11 3:08 ` Matthew Wilcox 2019-07-11 7:48 ` Jan Kara 2019-07-11 7:48 ` Jan Kara 2019-07-11 13:28 ` Matthew Wilcox 2019-07-11 13:28 ` Matthew Wilcox 2019-07-11 3:35 ` Matthew Wilcox 2019-07-11 3:35 ` Matthew Wilcox 2019-07-11 8:06 ` Jan Kara 2019-07-11 8:06 ` Jan Kara
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190705191004.GC32320@bombadil.infradead.org \ --to=willy@infradead.org \ --cc=dan.j.williams@intel.com \ --cc=jack@suse.cz \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvdimm@lists.01.org \ --cc=openosd@gmail.com \ --cc=robert.barror@intel.com \ --cc=seema.pandit@intel.com \ --cc=stable@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.