On 25 May 2014, at 12:22, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>> On 24 May 2014, at 20:16, Christos Zoulas wrote:
>>
>>> In article ,
>>> J. Hannken-Illjes wrote:
Why didn't you commit it then?
>>>
>>> I just did.
>>
>> I mean this: "selector and cont
In article ,
J. Hannken-Illjes wrote:
>On 24 May 2014, at 20:16, Christos Zoulas wrote:
>
>> In article ,
>> J. Hannken-Illjes wrote:
>>>
>>> Why didn't you commit it then?
>>
>> I just did.
>
>I mean this: "selector and context should be passed to
>vfs_vnode_iterator_init as they are invarian
On 5/24/2014 4:28 AM, Martin Husemann wrote:
On Fri, May 23, 2014 at 06:15:10PM +, Christos Zoulas wrote:
The hiccups are much less severe, but there are still performance
issues. The machine is a lot slower building than it used to be.
I see this as well (though no hard numbers). Amd64, f
On 24 May 2014, at 20:16, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>>
>> Why didn't you commit it then?
>
> I just did.
I mean this: "selector and context should be passed to
vfs_vnode_iterator_init as they are invariant."
Call as
vfs_vnode_iterator_init(mp, vip, sel
In article ,
J. Hannken-Illjes wrote:
>
>Why didn't you commit it then?
I just did.
>> We should review all the selector calls. I don't think that calling
>> VOP_GETATTR is ok. If it is not, why doesn't it KASSSET?
>
>If you mean ffs_snapshot.c, here the file system is suspended so no
>other thr
On 24 May 2014, at 19:32, Christos Zoulas wrote:
> In article <69ce1ce4-6c54-4e17-802d-679a6a165...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>>
>> Ok, see me convinced.
>
> Great :-)
>
>> First, selector and context should be passed to vfs_vnode_iterator_init
>> as they are invariant. We
In article <69ce1ce4-6c54-4e17-802d-679a6a165...@eis.cs.tu-bs.de>,
J. Hannken-Illjes wrote:
>
>Ok, see me convinced.
Great :-)
>First, selector and context should be passed to vfs_vnode_iterator_init
>as they are invariant. We may (ab)use v_mount and v_data to avoid
>allocating a state like we
On 23 May 2014, at 20:15, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>>
>> Ok, so I tried a kernel with DEBUG+LOCKDEBUG and get the same problems
>> you describe: every 10 to 20 seconds I get hickups of 1 to 2 seconds.
>>
>> Christos, just to make it clear: Do you have
chris...@astron.com (Christos Zoulas) wrote:
> <...>
>
> I still feel that for low power machines the filtering iterator is
> a much better answer, since it avoids a lot of extra work. Why
> lock and unlock the mntvnode lock and vget() something you are not
> going to use. At least add the ability
On Fri, May 23, 2014 at 06:15:10PM +, Christos Zoulas wrote:
> I still feel that for low power machines the filtering iterator is
> a much better answer, since it avoids a lot of extra work. Why
> lock and unlock the mntvnode lock and vget() something you are not
> going to use. At least ad
On Thu, May 22, 2014 at 07:42:51PM +0200, J. Hannken-Illjes wrote:
>
> While I'm interested in the results, this change is wrong. As long as
> we have forced unmount and revoke it is not safe to access an inode
> without locking the corresponding vnode. Holding a reference to the
> vnode just gu
On Fri, May 23, 2014 at 06:15:10PM +, Christos Zoulas wrote:
> The hiccups are much less severe, but there are still performance
> issues. The machine is a lot slower building than it used to be.
I see this as well (though no hard numbers). Amd64, ffs with log as root,
no raid.
Martin
In article ,
J. Hannken-Illjes wrote:
>
>Ok, so I tried a kernel with DEBUG+LOCKDEBUG and get the same problems
>you describe: every 10 to 20 seconds I get hickups of 1 to 2 seconds.
>
>Christos, just to make it clear: Do you have these problems when
>running a GENERIC or better GENERIC -DIAGNOS
On Fri, May 23, 2014 at 10:56:31AM +0200, J. Hannken-Illjes wrote:
> > Note that the ffs code did not take the
> > interlock before (so before the iterator changes it was unsafe). The
> > machine performance is now back where it was. Without the patch
> > the performance regression was so bad,
On 22 May 2014, at 13:27, Christos Zoulas wrote:
> In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>> On 22 May 2014, at 03:15, Christos Zoulas wrote:
>>
>>> In article ,
>>> Christos Zoulas wrote:
>>> Although this improves the situation the mac
In article <881bae49-9d0e-474e-9bc2-16230f304...@eis.cs.tu-bs.de>,
J. Hannken-Illjes wrote:
>On 23 May 2014, at 13:42, Christos Zoulas wrote:
>
>> In article <09108bb8-536e-48e2-906e-cdf6e0962...@eis.cs.tu-bs.de>,
>> J. Hannken-Illjes wrote:
>>>
>>> Does the attached diff help?
>>
>> No, I don
On 23 May 2014, at 13:42, Christos Zoulas wrote:
> In article <09108bb8-536e-48e2-906e-cdf6e0962...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>>
>> Does the attached diff help?
>
> No, I don't think it does.
Christos, please try it. Of the locks involved locking the vnode is the
one that
In article <09108bb8-536e-48e2-906e-cdf6e0962...@eis.cs.tu-bs.de>,
J. Hannken-Illjes wrote:
>
>Does the attached diff help?
No, I don't think it does. As I said all operation suffer, not just sync.
Doing 150K locks and unlocks and vget/vrele without needing it makes the
system unusable. This need
On 23 May 2014, at 01:50, Christos Zoulas wrote:
> In article ,
> J. Hannken-Illjes wrote:
>>
>> While I'm interested in the results, this change is wrong. As long as
>> we have forced unmount and revoke it is not safe to access an inode
>> without locking the corresponding vnode. Holding a r
In article ,
J. Hannken-Illjes wrote:
>
>While I'm interested in the results, this change is wrong. As long as
>we have forced unmount and revoke it is not safe to access an inode
>without locking the corresponding vnode. Holding a reference to the
>vnode just guarantees the vnode will not disap
On May 22, 6:23pm, campbell+netbsd-tech-k...@mumble.net (Taylor R Campbell)
wrote:
-- Subject: Re: serious performance regression in .41
|Date: Thu, 22 May 2014 16:47:10 + (UTC)
|From: chris...@astron.com (Christos Zoulas)
|
|I am testing this now:
|
|http://www.netbsd.org
Date: Thu, 22 May 2014 16:47:10 + (UTC)
From: chris...@astron.com (Christos Zoulas)
I am testing this now:
http://www.netbsd.org/~christos/vnode_iterator.diff
vfs_vnode_iterator_next should take the interlock and check for
VI_CLEAN|VI_CHANGING (and perhaps vwait if VI_CHANGING) b
On 22 May 2014, at 18:47, Christos Zoulas wrote:
> In article <2b9bf96f-5db2-4b91-8fd0-a01f0f455...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>> On 22 May 2014, at 13:27, Christos Zoulas wrote:
>>
>>> In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis.cs.tu-bs.de>,
>>> J. Hannken-Illjes
In article <2b9bf96f-5db2-4b91-8fd0-a01f0f455...@eis.cs.tu-bs.de>,
J. Hannken-Illjes wrote:
>On 22 May 2014, at 13:27, Christos Zoulas wrote:
>
>> In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis.cs.tu-bs.de>,
>> J. Hannken-Illjes wrote:
>>> On 22 May 2014, at 03:15, Christos Zoulas wrote:
On 22 May 2014, at 13:27, Christos Zoulas wrote:
> In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis.cs.tu-bs.de>,
> J. Hannken-Illjes wrote:
>> On 22 May 2014, at 03:15, Christos Zoulas wrote:
>
>>> - start a build
>>> - hold a key down at the shell prompt and notice how it behaves
>>>
>
In article <0e8bfcfc-c4cd-4ce3-8bac-22eb8ebd3...@eis.cs.tu-bs.de>,
J. Hannken-Illjes wrote:
>On 22 May 2014, at 03:15, Christos Zoulas wrote:
>
>> In article ,
>> Christos Zoulas wrote:
>>
>>> Here's an ugly fix (but internally only ugly fix):
>>>
>>> http://www.netbsd.org/~christos/mntvnode_l
On 22 May 2014, at 03:15, Christos Zoulas wrote:
> In article ,
> Christos Zoulas wrote:
>
>> Here's an ugly fix (but internally only ugly fix):
>>
>> http://www.netbsd.org/~christos/mntvnode_lock.diff
Only unmount will use vflush() so this will not help.
> Although this improves the situati
I had problems after boot a nonstandard named kernel(renamed standard) from
not the root partition, when I had another kernel on the root with the standard
name /netbsd.
After boot from the root partition and a standard named kernel(/netbsd), better.
Ilia.
In article ,
Christos Zoulas wrote:
>Here's an ugly fix (but internally only ugly fix):
>
>http://www.netbsd.org/~christos/mntvnode_lock.diff
Although this improves the situation the machine still has large pauses.
- compile a kernel with lockdebug.
- start a build
- hold a key down at the shell
In article ,
Christos Zoulas wrote:
>In article <20140521164755.885ae14a...@mail.netbsd.org>,
>Mindaugas Rasiukevicius wrote:
>>chris...@zoulas.com (Christos Zoulas) wrote:
>>> Since my last upgrade (I think the last working has been .24), I've been
>>> getting very bad performance running "sync
In article <20140521164755.885ae14a...@mail.netbsd.org>,
Mindaugas Rasiukevicius wrote:
>chris...@zoulas.com (Christos Zoulas) wrote:
>> Since my last upgrade (I think the last working has been .24), I've been
>> getting very bad performance running "sync" and choppy interactive
>> response. It s
> | Elapsed time: 10.04 seconds.
>
> Do you have LOCKDEBUG on?
>
> christos
>
>
I think no.
It's the GENERIC from autobuild.
On May 21, 9:41pm, net...@izyk.ru (Ilia Zykov) wrote:
-- Subject: Re: serious performance regression in .41
| On 21.05.2014 20:08, Christos Zoulas wrote:
| > Hi,
| >
|
| I don't understand what do you mean.
| Maybe it is useful for statistics, when "tar xzf src
On 21.05.2014 20:08, Christos Zoulas wrote:
> Hi,
>
I don't understand what do you mean.
Maybe it is useful for statistics, when "tar xzf src.tgz" on 6.99.40.
lockstat sync
Elapsed time: 10.04 seconds.
-- Adaptive mutex spin
Total% Count Time/ms Lock Caller
chris...@zoulas.com (Christos Zoulas) wrote:
> Since my last upgrade (I think the last working has been .24), I've been
> getting very bad performance running "sync" and choppy interactive
> response. It seems something bad happens with locking when there are too
> many objects in the buffer cache,
Hi,
Since my last upgrade (I think the last working has been .24), I've been
getting very bad performance running "sync" and choppy interactive response.
It seems something bad happens with locking when there are too many objects
in the buffer cache, because rebooting makes the problem go away fo
36 matches
Mail list logo
