Re: Dynamic ticks in FreeBSD
Thank you for replying, and sorry for delaying to reply for my network reason. I'm very happy that you all give me very useful advice :D 2010/3/31 Andriy Gapon : > 1. Instead of firing clock (LAPIC timer) interrupt regularly with a frequency > derived from HZ, the interrupt is scheduled to fire (in one-shot mode) at the > time > of the soonest scheduled callout. > 2. The code also makes sure to run hard/stat/prof-clocks if time since last > interrupt is greater than their respective periods in !dyntick mode. Yes, that's right. > Thus, it appears that in dyntick mode hard/stat/prof-clocks would run > irregularly. > I couldn't find any code that makes sure that the rest of the system handles > this > properly. Perhaps I missed it, or is it still in progress/plans? Yeah, this is in progress. Next step is to support to hard/stat/prof-clocks run irregularly. Now, I'm reading code to understand how they work correctly in dyntick mode. > Also, I am not sure if the code handles the case when a new 'soonest' callout > is > scheduled after we already decided when to fire the next LAPIC timer > interrupt. In current version, this case is going to be ignored ( do nothing ). This is bug, and I'll fix it. 2010/3/31 Roman Divacky : > I wonder - why don't we store the callouts in binary > tree so the searching for nearest callout is faster? Is it time to have another look at callout queue implementation for this work? Or another implementation is to make callout queue have the nearest tick value. This costs O(1). > > what is the average length of the callout queue? I'm going to monitor it. 2010/3/31 Artem Belevich : > Are you doing anything to handle the case where the lapic timer is turned off > when a CPU enters C2 or C3? No. Hmm, this is very big problem. > The ideal approach in my mind would be to not use > the lapic timer at all when running in a deadline mode, but give each CPU a > dedicated HPET comparator. Alternatively, you could add some special handling > where CPU 0 never goes into C2 or C3 but sends IPIs to other CPUs in deep idle > states when necessary (you could also let CPU 0 fake statclock() for said > CPUs > as well perhaps). I see. In SMP environment, this seems to be very good. I'll try to implement next version by using HPET. 2010/3/31 Artem Belevich : > It may be worth it to look at Solaris' cyclic facillity for ideas. > sys/cddl/dev/cyclic/cyclic.c Thanks! I'll read it. 2010/3/31 Dag-Erling Smørgrav : >Never mind, Julian was making a joke at my expense. OK :D I wanna make next patch which is reflected your opinions by the end of April. Thank you! Very Truly yours Tsuyoshi Ozawa -- Tsuyoshi Ozawa ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: leak of the vnodes
BTW, the 7.3 seems be unaffected by this.
Confirmed, the whole build of gcc-4.3 ends with
kern.maxvnodes: 10
kern.minvnodes: 25000
vfs.freevnodes: 22070
vfs.wantfreevnodes: 25000
vfs.numvnodes: 39907
debug.vnlru_nowhere: 0
while for 8.0 kernel even 12 in vfs.numvnodes does not suffice.
BTW, can you check latest RELENG_8 kernel, or HEAD, for the issue ?
Both are affected, the ddb output bellow is from svn206142 for HEAD.
Are all vnodes in some mountpoint ? What pipes and sockets ?
I do not quite understand the question.
Pipes and sockets are not vnodes, and I want to see what type of
filesystem (UFS or devfs) leaks.
I lowered max to get problem earlier
kern.maxvnodes: 4
kern.minvnodes: 25000
vfs.freevnodes: 0
vfs.wantfreevnodes: 25000
vfs.numvnodes: 37934
debug.vnlru_nowhere: 83
I would expect that sum of mnt_nvnodelistsize should be vfs.numvnodes.
The sum is at about 3400, but the vfs.numvnodes is at about 38000.
Is my expectation correct ?
Petr
db> show mount
0xff0003939be0 /dev/ad0s2a on / (ufs)
0xff000393a000 devfs on /dev (devfs)
0xff00039398e8 linprocfs on /proc (linprocfs)
0xff0009b9d000 /dev/ad0s2d on /opt/sid/build (ufs)
db> show mount 0xff0003939be0
0xff0003939be0 /dev/ad0s2a on / (ufs)
mnt_flag = LOCAL, ROOTFS
mnt_kern_flag = EXTENDED_SHARED, MPSAFE, LOOKUP_SHARED
mnt_opt = rw, fstype, fspath, from, errmsg, noro
mnt_stat = { version=537068824 type=7 flags=0x5000
bsize=2048 iosize=16384 blocks=9233079 bfree=1720773 bavail=982127
files=2402302 ffree=2211006 syncwrites=0 asyncwrites=0 syncreads=0
asyncreads=0 namemax=255 owner=0 fsid=[1208030997, -638345611] }
mnt_cred = { uid=0 ruid=0 }
mnt_ref = 647
mnt_gen = 1
mnt_nvnodelistsize = 647
mnt_writeopcount = 0
mnt_noasync = 0
mnt_maxsymlinklen = 120
mnt_iosize_max = 131072
mnt_hashseed = 3875541360
mnt_secondary_writes = 0
mnt_secondary_accwrites = 1674383
mnt_gjprovider = NULL
db> show mount 0xff000393a000
0xff000393a000 devfs on /dev (devfs)
mnt_flag = MULTILABEL, LOCAL
mnt_kern_flag = MPSAFE
mnt_opt =
mnt_stat = { version=537068824 type=2 flags=0x04001000 bsize=0
iosize=0 blocks=0 bfree=0 bavail=0 files=0 ffree=0 syncwrites=0
asyncwrites=0 syncreads=0 asyncreads=0 namemax=255 owner=0 fsid=[33619712,
2] }
mnt_cred = { uid=0 ruid=0 }
mnt_ref = 36
mnt_gen = 1
mnt_nvnodelistsize = 36
mnt_writeopcount = 0
mnt_noasync = 0
mnt_maxsymlinklen = 0
mnt_iosize_max = 65536
mnt_hashseed = 1577461787
mnt_secondary_writes = 0
mnt_secondary_accwrites = 0
mnt_gjprovider = NULL
db> show mount 0xff00039398e8
0xff00039398e8 linprocfs on /proc (linprocfs)
mnt_flag = LOCAL
mnt_kern_flag = MPSAFE
mnt_opt = fstype, fspath, from, errmsg
mnt_stat = { version=537068824 type=8 flags=0x1000
bsize=4096 iosize=4096 blocks=1 bfree=0 bavail=0 files=1 ffree=0
syncwrites=0 asyncwrites=0 syncreads=0 asyncreads=0 namemax=255 owner=0
fsid=[134283009, 8] }
mnt_cred = { uid=0 ruid=0 }
mnt_ref = 393
mnt_gen = 1
mnt_nvnodelistsize = 393
mnt_writeopcount = 0
mnt_noasync = 0
mnt_maxsymlinklen = 0
mnt_iosize_max = 65536
mnt_hashseed = 486483318
mnt_secondary_writes = 0
mnt_secondary_accwrites = 0
mnt_gjprovider = NULL
db> show mount 0xff0009b9d000
0xff0009b9d000 /dev/ad0s2d on /opt/sid/build (ufs)
mnt_flag = LOCAL
mnt_kern_flag = EXTENDED_SHARED, MPSAFE, LOOKUP_SHARED
mnt_opt = rw, fstype, fspath, from, errmsg, noro
mnt_stat = { version=537068824 type=7 flags=0x1000
bsize=2048 iosize=16384 blocks=9683239 bfree=4555857 bavail=3781198
files=2520062 ffree=168 syncwrites=0 asyncwrites=0 syncreads=0
asyncreads=0 namemax=255 owner=0 fsid=[1208030997, -1215882613] }
mnt_cred = { uid=0 ruid=0 }
mnt_ref = 2297
mnt_gen = 1
mnt_nvnodelistsize = 2296
mnt_writeopcount = 0
mnt_noasync = 0
mnt_maxsymlinklen = 120
mnt_iosize_max = 131072
mnt_hashseed = 1634023874
mnt_secondary_writes = 1
mnt_secondary_accwrites = 1332980
mnt_gjprovider = NULL
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: leak of the vnodes
On Mon, Apr 05, 2010 at 10:36:19PM +0200, Petr Salinger wrote:
> >>
> BTW, the 7.3 seems be unaffected by this.
> >>
> >>Confirmed, the whole build of gcc-4.3 ends with
> >>
> >>kern.maxvnodes: 10
> >>kern.minvnodes: 25000
> >>vfs.freevnodes: 22070
> >>vfs.wantfreevnodes: 25000
> >>vfs.numvnodes: 39907
> >>debug.vnlru_nowhere: 0
> >>
> >>while for 8.0 kernel even 12 in vfs.numvnodes does not suffice.
> >BTW, can you check latest RELENG_8 kernel, or HEAD, for the issue ?
>
> Both are affected, the ddb output bellow is from svn206142 for HEAD.
>
> >>Are all vnodes in some mountpoint ? What pipes and sockets ?
> >I do not quite understand the question.
> >
> >Pipes and sockets are not vnodes, and I want to see what type of
> >filesystem (UFS or devfs) leaks.
>
> I lowered max to get problem earlier
>
> kern.maxvnodes: 4
> kern.minvnodes: 25000
> vfs.freevnodes: 0
> vfs.wantfreevnodes: 25000
> vfs.numvnodes: 37934
> debug.vnlru_nowhere: 83
>
> I would expect that sum of mnt_nvnodelistsize should be vfs.numvnodes.
> The sum is at about 3400, but the vfs.numvnodes is at about 38000.
> Is my expectation correct ?
Not quite, reclaimed vnode is removed from mp list. Can you check
that vmstat -z | grep VNODE output coincides with sysctl vfs.numvnodes ?
Also, can you unmount linprocfs before the test and see whether it
leaks as before ?
Another thing to try is set sysctl debug.disablefullpath to 1.
Thanks.
>
> Petr
>
> db> show mount
>
> 0xff0003939be0 /dev/ad0s2a on / (ufs)
> 0xff000393a000 devfs on /dev (devfs)
> 0xff00039398e8 linprocfs on /proc (linprocfs)
> 0xff0009b9d000 /dev/ad0s2d on /opt/sid/build (ufs)
>
> db> show mount 0xff0003939be0
>
> 0xff0003939be0 /dev/ad0s2a on / (ufs)
> mnt_flag = LOCAL, ROOTFS
> mnt_kern_flag = EXTENDED_SHARED, MPSAFE, LOOKUP_SHARED
> mnt_opt = rw, fstype, fspath, from, errmsg, noro
> mnt_stat = { version=537068824 type=7 flags=0x5000
> bsize=2048 iosize=16384 blocks=9233079 bfree=1720773 bavail=982127
> files=2402302 ffree=2211006 syncwrites=0 asyncwrites=0 syncreads=0
> asyncreads=0 namemax=255 owner=0 fsid=[1208030997, -638345611] }
> mnt_cred = { uid=0 ruid=0 }
> mnt_ref = 647
> mnt_gen = 1
> mnt_nvnodelistsize = 647
> mnt_writeopcount = 0
> mnt_noasync = 0
> mnt_maxsymlinklen = 120
> mnt_iosize_max = 131072
> mnt_hashseed = 3875541360
> mnt_secondary_writes = 0
> mnt_secondary_accwrites = 1674383
> mnt_gjprovider = NULL
>
> db> show mount 0xff000393a000
>
> 0xff000393a000 devfs on /dev (devfs)
> mnt_flag = MULTILABEL, LOCAL
> mnt_kern_flag = MPSAFE
> mnt_opt =
> mnt_stat = { version=537068824 type=2 flags=0x04001000 bsize=0
> iosize=0 blocks=0 bfree=0 bavail=0 files=0 ffree=0 syncwrites=0
> asyncwrites=0 syncreads=0 asyncreads=0 namemax=255 owner=0 fsid=[33619712,
> 2] }
> mnt_cred = { uid=0 ruid=0 }
> mnt_ref = 36
> mnt_gen = 1
> mnt_nvnodelistsize = 36
> mnt_writeopcount = 0
> mnt_noasync = 0
> mnt_maxsymlinklen = 0
> mnt_iosize_max = 65536
> mnt_hashseed = 1577461787
> mnt_secondary_writes = 0
> mnt_secondary_accwrites = 0
> mnt_gjprovider = NULL
>
>
> db> show mount 0xff00039398e8
>
> 0xff00039398e8 linprocfs on /proc (linprocfs)
> mnt_flag = LOCAL
> mnt_kern_flag = MPSAFE
> mnt_opt = fstype, fspath, from, errmsg
> mnt_stat = { version=537068824 type=8 flags=0x1000
> bsize=4096 iosize=4096 blocks=1 bfree=0 bavail=0 files=1 ffree=0
> syncwrites=0 asyncwrites=0 syncreads=0 asyncreads=0 namemax=255 owner=0
> fsid=[134283009, 8] }
> mnt_cred = { uid=0 ruid=0 }
> mnt_ref = 393
> mnt_gen = 1
> mnt_nvnodelistsize = 393
> mnt_writeopcount = 0
> mnt_noasync = 0
> mnt_maxsymlinklen = 0
> mnt_iosize_max = 65536
> mnt_hashseed = 486483318
> mnt_secondary_writes = 0
> mnt_secondary_accwrites = 0
> mnt_gjprovider = NULL
>
>
> db> show mount 0xff0009b9d000
>
> 0xff0009b9d000 /dev/ad0s2d on /opt/sid/build (ufs)
> mnt_flag = LOCAL
> mnt_kern_flag = EXTENDED_SHARED, MPSAFE, LOOKUP_SHARED
> mnt_opt = rw, fstype, fspath, from, errmsg, noro
> mnt_stat = { version=537068824 type=7 flags=0x1000
> bsize=2048 iosize=16384 blocks=9683239 bfree=4555857 bavail=3781198
> files=2520062 ffree=168 syncwrites=0 asyncwrites=0 syncreads=0
> asyncreads=0 namemax=255 owner=0 fsid=[1208030997, -1215882613] }
> mnt_cred = { uid=0 ruid=0 }
> mnt_ref = 2297
> mnt_gen = 1
> mnt_nvnodelistsize = 2296
> mnt_writeopcount = 0
> mnt_noasync = 0
> mnt_maxsymlinklen = 120
> mnt_iosize_max = 131072
> mnt_hashseed = 1634023874
> mnt_secondary_writes = 1
> mnt_secondary_accwrites = 1332980
> mnt_gjprovider = NULL
>
pgpx1MDoQIIY8.pgp
Description: PGP signature
Re: grep
* Gabor Kovesdan [100330 08:52] wrote: > On 30/03/2010 20:00, Mark nesterovych wrote: > >Hi all. > > > >Decided to write BSD licensed grep and provide it to FreeBSD project if > >success. > > > > Dear Mark, > > this project is already completed and is going to be integrated to the > base system once portmgr can run an experimental build to make sure it > introduces no regressions. I suggest that you consider working on either > diff/sdiff or you can contribute to my sort implementation, which is not > totally completed yet. Hello, Where is diff/sdiff projects? thank you, -- - Alfred Perlstein .- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250 .- FreeBSD committer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
