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_b
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.
===
getti
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 creatin
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-scho
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 fas
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
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.
>
>
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 th
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: C
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
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 10
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 ab
* 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
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 fast
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
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, p
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
17 matches
Mail list logo