On Thu, Jan 16, 2020 at 04:51:44AM +0100, Mateusz Guzik wrote:
> On 1/15/20, Andrew Doran wrote:
> > I don't understand why we do this. I don't think it's needed at all
> > because
> > if the file really is deleted and the inode is getting cleaned out, then it
> > shouldn't be getting new refs i
To follow up: in testing this I ended up discovering a number of tedious,
complicated deadlocks that could occur due to softints, kernel_lock and
other factors. Trying to mitigate them killed the performance gain and it
still wasn't right. I'm abandoning this idea because in practice it seems
too
On Sun, Jan 19, 2020 at 09:50:24PM +, Andrew Doran wrote:
> Here's a dtrace flamegraph for a kernel build on my system, while running a
> kernel from the ad-namecache branch.
>
> http://www.netbsd.org/~ad/2020/jan19.svg
>
> The biggest single remaining concurency problem is the mutex o
On 1/21/20, Andrew Doran wrote:
> On Thu, Jan 16, 2020 at 04:51:44AM +0100, Mateusz Guzik wrote:
>>
>> I'm assuming the goal for the foreseeable future is to achieve path
>> lookup
>> with shared vnode locks.
>
> Good guess. There is a prototype of LK_SHARED lookup on the ad-namecache
> branch, a
On Tue, Jan 21, 2020 at 11:12:06PM +0100, Mateusz Guzik wrote:
>
> This does not happen with rb trees and would not happen with the hash
> table if there was bucket locking instead of per-cpu.
>
> I would stick to hash tables since they are easier to scale (both with
> and without locks).
>
> Fo
