Re: vm.ubc_direct
hi, 2019年12月4日(水) 2:58 Chuck Silvers : > On Mon, Dec 02, 2019 at 07:10:52PM +, Andrew Doran wrote: > > Hello, > > > > In light of the recent discussion, and having asked Jaromir his thoughts > on > > the subject, we both think it's time to enable this by default, so it > gets > > wider testing. Is there a good reason not to? > > > > Cheers, > > Andrew > > The current ubc_direct code still has the problem that I pointed out > originally, > which is that it deadlocks if you read() or write() a page of a file into > a mapping of itself. We should not enable this by default until that > problem > is fixed. > i guess it's safe if the vnode is !VV_MAPPED. > > -Chuck >
Re: vm.ubc_direct
I've submitted http://gnats.netbsd.org/54759 for the problem, includes also the program to trigger it. Le mer. 4 déc. 2019 à 14:08, Andrew Doran a écrit : > On Tue, Dec 03, 2019 at 11:28:07PM +0100, Jarom?r Dole?ek wrote: > > > Le mar. 3 d?c. 2019 ? 18:59, Chuck Silvers a ?crit : > > > > > On Mon, Dec 02, 2019 at 07:10:52PM +, Andrew Doran wrote: > > > > Hello, > > > > > > > > In light of the recent discussion, and having asked Jaromir his > thoughts > > > on > > > > the subject, we both think it's time to enable this by default, so it > > > gets > > > > wider testing. Is there a good reason not to? > > > > > > > > Cheers, > > > > Andrew > > > > > > The current ubc_direct code still has the problem that I pointed out > > > originally, > > > which is that it deadlocks if you read() or write() a page of a file > into > > > a mapping of itself. We should not enable this by default until that > > > problem > > > is fixed. > > > > > > > Right, I completely forgot about this. > > > > I have a small program which triggers the deadlock quite reliably. Never > > got around to actually add it into test suite because it caused problems > > also on other system I run it on. > > > > Andrew, would you by chance be interested to look at this? > > Yes I am, but I think it'll be next year some time if I do as there are > more > items on my list. Could you please send me the test program anyway? > > Incidentally I saw a thundering herd problem with this enabled (PG_WANTED > vs. wakeup()). From a quick look it seems like more of a general UBC > problem than a problem with ubc_direct but definitely something that needs > looking into. It could be mitigated somewhat with wakeup_one() and > associated changes but would be nice to address the root cause. This was > actually kind of amusing to watch in top(1), I wish I had a video: > > http://www.netbsd.org/~ad/sh.txt > > Andrew >
Re: vm.ubc_direct
On Tue, Dec 03, 2019 at 11:28:07PM +0100, Jarom?r Dole?ek wrote: > Le mar. 3 d?c. 2019 ? 18:59, Chuck Silvers a ?crit : > > > On Mon, Dec 02, 2019 at 07:10:52PM +, Andrew Doran wrote: > > > Hello, > > > > > > In light of the recent discussion, and having asked Jaromir his thoughts > > on > > > the subject, we both think it's time to enable this by default, so it > > gets > > > wider testing. Is there a good reason not to? > > > > > > Cheers, > > > Andrew > > > > The current ubc_direct code still has the problem that I pointed out > > originally, > > which is that it deadlocks if you read() or write() a page of a file into > > a mapping of itself. We should not enable this by default until that > > problem > > is fixed. > > > > Right, I completely forgot about this. > > I have a small program which triggers the deadlock quite reliably. Never > got around to actually add it into test suite because it caused problems > also on other system I run it on. > > Andrew, would you by chance be interested to look at this? Yes I am, but I think it'll be next year some time if I do as there are more items on my list. Could you please send me the test program anyway? Incidentally I saw a thundering herd problem with this enabled (PG_WANTED vs. wakeup()). From a quick look it seems like more of a general UBC problem than a problem with ubc_direct but definitely something that needs looking into. It could be mitigated somewhat with wakeup_one() and associated changes but would be nice to address the root cause. This was actually kind of amusing to watch in top(1), I wish I had a video: http://www.netbsd.org/~ad/sh.txt Andrew
Re: vm.ubc_direct
Le mar. 3 déc. 2019 à 18:59, Chuck Silvers a écrit : > On Mon, Dec 02, 2019 at 07:10:52PM +, Andrew Doran wrote: > > Hello, > > > > In light of the recent discussion, and having asked Jaromir his thoughts > on > > the subject, we both think it's time to enable this by default, so it > gets > > wider testing. Is there a good reason not to? > > > > Cheers, > > Andrew > > The current ubc_direct code still has the problem that I pointed out > originally, > which is that it deadlocks if you read() or write() a page of a file into > a mapping of itself. We should not enable this by default until that > problem > is fixed. > Right, I completely forgot about this. I have a small program which triggers the deadlock quite reliably. Never got around to actually add it into test suite because it caused problems also on other system I run it on. Andrew, would you by chance be interested to look at this? Jaromir
Re: vm.ubc_direct
On Tue, Dec 03, 2019 at 09:58:39AM -0800, Chuck Silvers wrote: > The current ubc_direct code still has the problem that I pointed out > originally, > which is that it deadlocks if you read() or write() a page of a file into > a mapping of itself. We should not enable this by default until that problem > is fixed. I didn't know about that. Agree enabling it would be a bad idea then. Cheers, Andrew
Re: vm.ubc_direct
On Mon, Dec 02, 2019 at 07:10:52PM +, Andrew Doran wrote: > Hello, > > In light of the recent discussion, and having asked Jaromir his thoughts on > the subject, we both think it's time to enable this by default, so it gets > wider testing. Is there a good reason not to? > > Cheers, > Andrew The current ubc_direct code still has the problem that I pointed out originally, which is that it deadlocks if you read() or write() a page of a file into a mapping of itself. We should not enable this by default until that problem is fixed. -Chuck
Re: vm.ubc_direct
Can you send the dmesg and log of the recoverable I/O errors? Jaromir Le mer. 20 nov. 2019 à 15:04, Robert Nestor a écrit : > I tried enabling this option on my amd64 system running a fairly recent > version of -current off a new SSD. While building some packages I noticed > a lot of recoverable disk I/O errors (mainly on writes) on the SSD disk. > After disabling this option and doing a similar set of package build I > didn’t see any recoverable disk I/O errors. I didn’t do any further > testing, but can if someone wants to look into this and needs additional > information.
Re: vm.ubc_direct
On Mon, Dec 02, 2019 at 08:30:58PM +0100, Kamil Rytarowski wrote: > On 02.12.2019 20:10, Andrew Doran wrote: > > Hello, > > > > In light of the recent discussion, and having asked Jaromir his thoughts on > > the subject, we both think it's time to enable this by default, so it gets > > wider testing. Is there a good reason not to? > > > > Cheers, > > Andrew > > > > There were reported issues in this mail: > > https://mail-index.netbsd.org/current-users/2019/11/20/msg037077.html Yup. I have seen that and am looking for further experiences with it. If someone does run into problems, they can turn it off with the sysctl (and hopefully get us some information about the failure). Cheers, Andrew
Re: vm.ubc_direct
On 02.12.2019 20:10, Andrew Doran wrote: > Hello, > > In light of the recent discussion, and having asked Jaromir his thoughts on > the subject, we both think it's time to enable this by default, so it gets > wider testing. Is there a good reason not to? > > Cheers, > Andrew > There were reported issues in this mail: https://mail-index.netbsd.org/current-users/2019/11/20/msg037077.html signature.asc Description: OpenPGP digital signature
vm.ubc_direct
Hello, In light of the recent discussion, and having asked Jaromir his thoughts on the subject, we both think it's time to enable this by default, so it gets wider testing. Is there a good reason not to? Cheers, Andrew
Re: vm.ubc_direct
I tried enabling this option on my amd64 system running a fairly recent version of -current off a new SSD. While building some packages I noticed a lot of recoverable disk I/O errors (mainly on writes) on the SSD disk. After disabling this option and doing a similar set of package build I didn’t see any recoverable disk I/O errors. I didn’t do any further testing, but can if someone wants to look into this and needs additional information.
Re: vm.ubc_direct
On Thu, Nov 14, 2019 at 03:44:54PM +0200, Andreas Gustafsson wrote: > Patrick Welche wrote: > > I have been running with vm.ubc_direct=1 and feeling a speedup and no > > inconveniences on multicore systems. What are thoughts on having it as > > a default? > > No such option is documented, hence the question makes no sense. It is part of: http://gnats.netbsd.org/53124 A Ryzen was painfully slow, and I just noticed the difference on a 24-core machine which prompted the note. Cheers, Patrick
Re: vm.ubc_direct
Patrick Welche wrote: > I have been running with vm.ubc_direct=1 and feeling a speedup and no > inconveniences on multicore systems. What are thoughts on having it as > a default? No such option is documented, hence the question makes no sense. -- Andreas Gustafsson, g...@gson.org
vm.ubc_direct
I have been running with vm.ubc_direct=1 and feeling a speedup and no inconveniences on multicore systems. What are thoughts on having it as a default? Cheers, Patrick
