Re: sysctl way too slow
Atom Smasher writes:
> http://smasher.org/tmp/zsh-bsd-sysctl-slow.png
>
> is there a way to get this information that doesn't take so long?
If you only need sysctl values for fancy prompt then cache them inside
variables, e.g.
PROMPT='($hw_acpi_battery_life, $hw_acpi_battery_time,
$hw_acpi_battery_state) %# '
PERIOD=30
setopt promptsubst
periodic_functions+=(sysctl-to-var)
sysctl-to-var() {
set -- hw.acpi.battery.
for i in $(sysctl -N $@); do
eval ${i:gs/./_/:gs/%//}='$(sysctl -n $i)'
done
}
To not pollute global scope using one associative array for sysctls may
be better.
>
> the same info is available on linux via /sys and /proc and on
> comparable hardware, i can get the info about 100x faster.
>
> thanks...
___
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: sysctl way too slow
On Wed, 14 Jul 2010, Ed Schouten wrote: So what about other sysctls? Is it just these sysctls? It may be the case that these values are not simply read from some variable in the kernel, but really performs some hardware calls. Still, 436 msec is quite a lot of time. === getting the same info on a linux box from /sys/class/power_supply/BAT0/* takes <10ms, even when reading all 32 files in the directory. meanwhile, on freebsd, the other hw.acpi.* variables i've tried are either reasonably fast (2-7 mS) or as slow, but no slower. at least not the handful that i've tried. hw.acpi.battery.* are the ones i'm actually interested in. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - "About all you can do in life is be who you are. Some people will love you for you. Most will love you for what you can do for them, and some won't like you at all." -- Rita Mae Brown ___ 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: an alternative to powerpoint
On Wed 14 Jul 2010 at 12:54:20 PDT Charlie Kester wrote: On Tue 13 Jul 2010 at 06:17:06 PDT Peter Pentchev wrote: Just as an aside, though - are you aware of Eric Meyer's S5, also available in your friendly neighbourhood Ports Collection as textproc/s5? :) Yet another alternative for creating presentations is misc/xsw. Or, if you're an old-school textmode type, misc/tpp. and if you're really oldschool and troff is your thing, you might be interested in http://repo.cat-v.org/troff-slider/ :) ___ 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: an alternative to powerpoint
On Tue 13 Jul 2010 at 06:17:06 PDT Peter Pentchev wrote: Just as an aside, though - are you aware of Eric Meyer's S5, also available in your friendly neighbourhood Ports Collection as textproc/s5? :) Yet another alternative for creating presentations is misc/xsw. Or, if you're an old-school textmode type, misc/tpp. ___ 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: sysctl way too slow
On Wed, Jul 14, 2010 at 10:08 AM, Atom Smasher wrote: > On Wed, 14 Jul 2010, Joerg Sonnenberger wrote: > > On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: >> >>> the same info is available on linux via /sys and /proc and on comparable >>> hardware, i can get the info about 100x faster. >>> >> >> Are you sure that Linux is not just caching the data? I know of at least >> one system where it takes more than 100ms to query the battery state due to >> extremely slow hardware, I wouldn't be surprised if you can do worse. >> > == > > i don't know if linux is caching it. if it is, then freebsd should at least > have an option to do the same. the real test will be trying linux on the > freebsd hardware and freebsd on the linux hardware. i don't know when i'll > get a chance to do it, but i'll update the list with details when it > happens. > FWIW, my old dell > /usr/bin/time sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 100 -1 0 0.01 real 0.00 user 0.01 sys -- Adam Vande More ___ 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: sysctl way too slow
On Wed, 14 Jul 2010, Joerg Sonnenberger wrote: On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: the same info is available on linux via /sys and /proc and on comparable hardware, i can get the info about 100x faster. Are you sure that Linux is not just caching the data? I know of at least one system where it takes more than 100ms to query the battery state due to extremely slow hardware, I wouldn't be surprised if you can do worse. == i don't know if linux is caching it. if it is, then freebsd should at least have an option to do the same. the real test will be trying linux on the freebsd hardware and freebsd on the linux hardware. i don't know when i'll get a chance to do it, but i'll update the list with details when it happens. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - "Anyone who doubts that terrorists could smuggle a nuclear warhead into New York City should note that they could always wrap it in a bale of marijuana." -- Graham Allison, The Boston Globe 27 October 1999 ___ 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: disk I/O, VFS hirunningspace
On Wed, Jul 14, 2010 at 12:04 AM, Gary Jennejohn wrote: > > > Rather than commenting out the code try setting the sysctl > vfs.hirunningspace to various powers-of-two. Default seems to be > 1MB. I just changed it on the command line as a test to 2MB. > > You can do this in /etc/sysctl.conf. > > thank you all, that did it. The settings that Matt recommended are giving the same numbers I had with the code commented out. I was concerned that the lock or msleep may be a problem. Jerry ___ 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: sysctl way too slow
In the last episode (Jul 14), Joerg Sonnenberger said: > On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: > > the same info is available on linux via /sys and /proc and on comparable > > hardware, i can get the info about 100x faster. > > Are you sure that Linux is not just caching the data? I know of at least > one system where it takes more than 100ms to query the battery state due > to extremely slow hardware, I wouldn't be surprised if you can do worse. I have an old Dell laptop where it takes almost a full second to fetch battery data via ACPI. -- Dan Nelson dnel...@allantgroup.com ___ 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"
8.1RC2 amd64 machine check question
Got the following in /var/log/messages on my one-week-old amd64 box running 8.1RC2: Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0106, Status 0x Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, APIC ID 0 Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c I read through sys/amd64/amd64/mca.c and it seems to be a correctable error on my L3 cache, but I am not 100% sure I am interpreting it correctly. Motherboard is an ASUS M4A785TD-V EVO w/ 2x 2GB ECC RAM and and an AMD Phenom X2: FreeBSD 8.1-RC2 #0: Tue Jun 29 20:21:55 UTC 2010 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) II X2 550 Processor (3113.67-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f43 Family = 10 Model = 4 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4112510976 (3921 MB) ACPI APIC Table: <041510 APIC1115> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 My questions are: 1. Did I interpret the message correctly (correctable error on my L3 cache)? 2. Is it anything to worry about? Or is this just one of those things that happens but now it gets logged whereas before I was blissfully ignorant? thanks, andrew ___ 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: sysctl way too slow
On Wed, 14 Jul 2010, Dominic Fandrey wrote: It probably depends on your BIOS. This is the same call on my system: % time sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 100 -1 0 sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 0.00s user 0.01s system 96% cpu 0.013 total As you can see 33 times faster than on your system. === next time i reboot this laptop, i'll stick an ubuntu CD in and see if it takes as long to get the info. i guess if it does take as long, then we can blame the hardware. -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - "Since I entered politics, I have chiefly had men's views confided to me privately. Some of the biggest men in the United States, in the Field of commerce and manufacture, are afraid of something. They know that there is a power somewhere so organized, so subtle, so watchful, so interlocked, so complete, so pervasive, that they better not speak above their breath when they speak in condemnation of it." -- Woodrow Wilson, The New Freedom (1913) ___ 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: sysctl way too slow
On Wed, Jul 14, 2010 at 11:49:07PM +1200, Atom Smasher wrote: > the same info is available on linux via /sys and /proc and on > comparable hardware, i can get the info about 100x faster. Are you sure that Linux is not just caching the data? I know of at least one system where it takes more than 100ms to query the battery state due to extremely slow hardware, I wouldn't be surprised if you can do worse. Joerg ___ 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: sysctl way too slow
On 14/07/2010 13:49, Atom Smasher wrote: > http://smasher.org/tmp/zsh-bsd-sysctl-slow.png Why use a screen shot here? > is there a way to get this information that doesn't take so long? > > the same info is available on linux via /sys and /proc and on comparable > hardware, i can get the info about 100x faster. It probably depends on your BIOS. This is the same call on my system: % time sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 100 -1 0 sysctl -n hw.acpi.battery.life hw.acpi.battery.time hw.acpi.battery.state 0.00s user 0.01s system 96% cpu 0.013 total As you can see 33 times faster than on your system. I agree that 0.413 seconds is too long, but I don't think it makes sense to call this value more frequently than every 30 seconds. So I'd say it's more of an annoyance than a real problem. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: sysctl way too slow
* Atom Smasher wrote: > http://smasher.org/tmp/zsh-bsd-sysctl-slow.png > > is there a way to get this information that doesn't take so long? > > the same info is available on linux via /sys and /proc and on > comparable hardware, i can get the info about 100x faster. So what about other sysctls? Is it just these sysctls? It may be the case that these values are not simply read from some variable in the kernel, but really performs some hardware calls. Still, 436 msec is quite a lot of time. -- Ed Schouten WWW: http://80386.nl/ pgpcbRRsFxAZF.pgp Description: PGP signature
Re: sysctl way too slow
On Wednesday 14 July 2010 13:49:07 Atom Smasher wrote: > http://smasher.org/tmp/zsh-bsd-sysctl-slow.png > > is there a way to get this information that doesn't take so long? > > the same info is available on linux via /sys and /proc and on comparable > hardware, i can get the info about 100x faster. > > thanks... Maybe you are using the sysctls wrong. Did you read man 3 sysctl? --HPS ___ 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"
sysctl way too slow
http://smasher.org/tmp/zsh-bsd-sysctl-slow.png is there a way to get this information that doesn't take so long? the same info is available on linux via /sys and /proc and on comparable hardware, i can get the info about 100x faster. thanks... -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - "I brainwashed youngsters into doing wrong. I want to say I'm sorry to children everywhere for selling out to concerns who make millions by murdering animals." -- Geoffrey Guiliano, the original Ronald McDonald actor who quit and publicly apologized. http://www.mcspotlight.org/people/interviews/guilliano_geoff.html ___ 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: How change process flags from userland?
Hi, I resolve this problem (thanks Julian Elischer for his thoughts): === int fd; int cnt; off_t off; void *p; kvm_t *kd; struct kinfo_proc *kip; struct proc *p_mmap; kd = kvm_open(NULL, _PATH_MEM, NULL, O_RDONLY, NULL); kip = kvm_getprocs(kd, KERN_PROC_PID, pid, &cnt); fd = open(_PATH_KMEM, O_RDWR, 0); off = (off_t)((uintptr_t)kip->ki_paddr); p = mmap(0, sizeof(struct proc), PROT_READ | PROT_WRITE, MAP_SHARED, fd, off); p_mmap = (struct proc *)p; p_mmap->p_flag |= P_PROTECTED; ... === I wrote daemon [1] that set P_PROTECTED flag for applications. May be it useful for someone. [1] http://zonov.pp.ru/pprotectd/pprotectd.tbz -- Andrey Zonov 2010/6/30 Andrey Zonov : > Hi, > > I want to set P_PROTECTED flag for some daemons after it start, without > patching application and kernel. > It possible? ___ 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: disk I/O, VFS hirunningspace
On Tue, 13 Jul 2010 15:34:12 -0700
Jerry Toung wrote:
> Hello List,
> I am on 8.0 RELEASE amd64. My system has 2 RAID arrays connected to 2
> separate
> controllers.
> My I/O throughput tests jumped by ~100MB/sec on both channels, when I
> commented out the
> following piece of code from kern/vfs_bio.c
>
> void
> waitrunningbufspace(void)
> {
> /*
> mtx_lock(&rbreqlock);
> while (runningbufspace > hirunningspace) {
> ++runningbufreq;
> msleep(&runningbufreq, &rbreqlock, PVM, "wdrain", 0);
> }
> mtx_unlock(&rbreqlock);
> */
> }
>
> so far, I can't observe any side effects of not running it. Am I on a time
> bomb?
>
Rather than commenting out the code try setting the sysctl
vfs.hirunningspace to various powers-of-two. Default seems to be
1MB. I just changed it on the command line as a test to 2MB.
You can do this in /etc/sysctl.conf.
--
Gary Jennejohn
___
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"
