Re: Spin down HDD after disk sync or before power off

2009-03-08 Thread Bernd Walter
On Fri, Mar 06, 2009 at 03:47:38PM -0600, Rick C. Petty wrote:
> On Fri, Mar 06, 2009 at 03:30:14PM -0600, Octavian Covalschi wrote:
> > Why is spinning down is bad for HDD ? I believe it's better to spindown a
> > drive,
> > instead of cutting power too sudden.
> 
> Comparing those two, I'd say it shouldn't matter (although probably a
> forced spindown may be better).  But pulling power from a drive does not
> mean the drive immediately stops doing stuff.

My understanding is that without power the heads just slamm into
landing zone, while it can be done in a controlled smooth way with
power.

> I was just saying spindown on disks is bad in the first place.  Sure, you
> might save some wear and tear on the bearings, but you risk problems with
> the heads on both spindown and spinup.  In other words, if you can avoid
> power-cycling your drives, they should last longer (in that you're less
> likely to destroy the heads).

This depends on the disks.
Desktop and especially mobile drives are designed to sustain more
spin downs, but are not designed for rotating a long time.
But of course if you intend to spin up directly after spin down it
might be bad for them as well, since it isn't really saving spinning
time.
This is nothing, which should be done on reboot, but for halts it
might be reasonable to do.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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"


CPU user/kernel time given the PID

2009-03-08 Thread Jay Loden
I'm working on FreeBSD support for a Python library called psutil for reading
process information in a cross-platform fashion. Each platform-specific module
is written in C, so the majority of the FreeBSD code is a C interface to various
process information. I've been having some trouble working out how to get CPU
user/kernel time for a given PID. I took a look at the source to top and ps but
neither really helped since they don't seem to cover the info I was looking for
(or I missed it).

I'm not sure if there's a better way to go about this but I've been looking at
sysctl and the kinfo_proc struct - is there somewhere more appropriate to
retrieve this information? If the kinfo_proc struct is the way to go, then do I
want to use ki_runtime, ki_swtime or something else, and does that mean there's
no distinction between user/kern time for a process? If anyone has code samples
or recommended docs to get me pointed in the right direction that would be 
great.

Thanks,

-Jay
___
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: uma_zone

2009-03-08 Thread Alexej Sokolov
2009/3/7 Robert Watson 

> On Wed, 4 Mar 2009, Alexej Sokolov wrote:
>
>  how can I get the size and pointer of some allocated uma zone ? For
>> example: zone_pack
>>
>
> Could you tell us a bit more about the context in which you want to do
> this?

Interrupt kontext.


> Normally kernel modules acquire pointers to globally visible zones via a
> symbol dependency resolved by the kernel linker (zone_pack is a globally
> visible symbol in the kernel).


But what about the size ? Do the UMA zones have fixed sizes? What I want to
do is to remap zone_pack into the user space in order to give user
applications access to mbuf clusters with frames.


> Our general userspace monitoring tools, such as vmstat -z, don't display
> the UMA zone pointers, and a pointer to the zone is not exported by the
> sysctls it depends on, currently, but if you run kgdb on kernel.symbols you
> should be able to print out the address of the global zone_pack directly.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge


Thanx a lot!
___
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: CPU user/kernel time given the PID

2009-03-08 Thread Oliver Fromme
Jay Loden wrote:
 > I'm working on FreeBSD support for a Python library called psutil for reading
 > process information in a cross-platform fashion. Each platform-specific 
 > module
 > is written in C, so the majority of the FreeBSD code is a C interface to 
 > various
 > process information. I've been having some trouble working out how to get CPU
 > user/kernel time for a given PID. I took a look at the source to top and ps 
 > but
 > neither really helped since they don't seem to cover the info I was looking 
 > for
 > (or I missed it).
 > 
 > I'm not sure if there's a better way to go about this but I've been looking 
 > at
 > sysctl and the kinfo_proc struct - is there somewhere more appropriate to
 > retrieve this information? If the kinfo_proc struct is the way to go, then 
 > do I
 > want to use ki_runtime, ki_swtime or something else, and does that mean 
 > there's
 > no distinction between user/kern time for a process? If anyone has code 
 > samples
 > or recommended docs to get me pointed in the right direction that would be 
 > great.

ps(1) and top(1) both use ki_pctcpu, see the getpcpu()
function in src/bin/ps/print.c and format_next_process()
in src/usr.bin/top/machine.c

As far as I know, there is no distinction between user-
mode and kernel-mode CPU time per process.  It should
also be noted that the kernel's time cannot always be
attributed to a certain userland process.  I would even
guess is that the majority of the CPU time spent in the
kernel is not on behalf of a specific userland process.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

"C is quirky, flawed, and an enormous success."
-- Dennis M. Ritchie.
___
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: CPU user/kernel time given the PID

2009-03-08 Thread Jay Loden
Oliver Fromme wrote:
> ps(1) and top(1) both use ki_pctcpu, see the getpcpu()
> function in src/bin/ps/print.c and format_next_process()
> in src/usr.bin/top/machine.c

Hi Oliver, thanks for the reply. I noticed the same after some digging through
the source code for ps and top. While CPU usage % is a useful number also, I was
hoping to be able to get CPU time(s). Possibly that information simply isn't
available on FreeBSD like it is for other OSes.

> As far as I know, there is no distinction between user-
> mode and kernel-mode CPU time per process.  It should
> also be noted that the kernel's time cannot always be
> attributed to a certain userland process.  I would even
> guess is that the majority of the CPU time spent in the
> kernel is not on behalf of a specific userland process.

I would suspect the same, but I did notice that times() does return separate
values for user/system time on FreeBSD, so that implies that the system is able
to differentiate between the two somehow. If you can get it from within the
current running process the data must be there but I've no idea what interface
(if any) exists to read that information for other processes.

-Jay
___
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: CPU user/kernel time given the PID

2009-03-08 Thread Dan Nelson
In the last episode (Mar 08), Jay Loden said:
> Oliver Fromme wrote:
> > ps(1) and top(1) both use ki_pctcpu, see the getpcpu() function in
> > src/bin/ps/print.c and format_next_process() in
> > src/usr.bin/top/machine.c
> 
> Hi Oliver, thanks for the reply. I noticed the same after some digging
> through the source code for ps and top.  While CPU usage % is a useful
> number also, I was hoping to be able to get CPU time(s).  Possibly that
> information simply isn't available on FreeBSD like it is for other OSes.

I was wondering why you were having so much trouble finding what you were
looking for, and then I realized I have a patch that I have never submitted
a PR for: the addition of "systime" and "usertime" ps keywords :) It simply
reads the rusage struct, and returns the same values that getrusage() does.

-- 
Dan Nelson
dnel...@allantgroup.com
Index: extern.h
===
RCS file: /home/ncvs/src/bin/ps/extern.h,v
retrieving revision 1.37
diff -u -p -r1.37 extern.h
--- extern.h23 Jun 2004 23:48:09 -  1.37
+++ extern.h7 Jan 2005 06:46:15 -
@@ -78,11 +78,13 @@ int  s_uname(KINFO *);
 voidshowkey(void);
 voidstarted(KINFO *, VARENT *);
 voidstate(KINFO *, VARENT *);
+voidsystime(KINFO *, VARENT *);
 voidtdev(KINFO *, VARENT *);
 voidtname(KINFO *, VARENT *);
 voiducomm(KINFO *, VARENT *);
 voiduname(KINFO *, VARENT *);
 voidupr(KINFO *, VARENT *);
+voidusertime(KINFO *, VARENT *);
 voidvsize(KINFO *, VARENT *);
 voidwchan(KINFO *, VARENT *);
 __END_DECLS
Index: keyword.c
===
RCS file: /home/ncvs/src/bin/ps/keyword.c,v
retrieving revision 1.76
diff -u -p -r1.76 keyword.c
--- keyword.c   6 Apr 2006 03:24:31 -   1.76
+++ keyword.c   2 Mar 2007 17:23:10 -
@@ -185,6 +185,7 @@ static VAR var[] = {
UINT, UIDFMT, 0},
{"svuid", "SVUID", NULL, 0, kvar, NULL, UIDLEN, KOFF(ki_svuid),
UINT, UIDFMT, 0},
+   {"systime", "SYSTIME", NULL, USER, systime, NULL, 9, 0, CHAR, NULL, 0},
{"tdev", "TDEV", NULL, 0, tdev, NULL, 4, 0, CHAR, NULL, 0},
{"time", "TIME", NULL, USER, cputime, NULL, 9, 0, CHAR, NULL, 0},
{"tpgid", "TPGID", NULL, 0, kvar, NULL, 4, KOFF(ki_tpgid), UINT,
@@ -203,6 +204,7 @@ static VAR var[] = {
"lx", 0},
{"user", "USER", NULL, LJUST|DSIZ, uname, s_uname, USERLEN, 0, CHAR,
NULL, 0},
+   {"usertime", "USERTIME", NULL, USER, usertime, NULL, 9, 0, CHAR, NULL, 
0},
{"usrpri", "", "upr", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{"vsize", "", "vsz", 0, NULL, NULL, 0, 0, CHAR, NULL, 0},
{"vsz", "VSZ", NULL, 0, vsize, NULL, 5, 0, CHAR, NULL, 0},
Index: print.c
===
RCS file: /home/ncvs/src/bin/ps/print.c,v
retrieving revision 1.95
diff -u -p -r1.95 print.c
--- print.c 17 Sep 2007 05:27:18 -  1.95
+++ print.c 11 Oct 2007 19:54:02 -
@@ -551,6 +551,79 @@ cputime(KINFO *k, VARENT *ve)
 }
 
 void
+systime(KINFO *k, VARENT *ve)
+{
+   VAR *v;
+   long secs;
+   long psecs; /* "parts" of a second. first micro, then centi */
+   char obuff[128];
+   static char decimal_point;
+
+   if (decimal_point == '\0')
+   decimal_point = localeconv()->decimal_point[0];
+   v = ve->var;
+   if (!k->ki_valid) {
+   secs = 0;
+   psecs = 0;
+   } else {
+   /*
+* This counts time spent handling interrupts.  We could
+* fix this, but it is not 100% trivial (and interrupt
+* time fractions only work on the sparc anyway).   XXX
+*/
+   secs = k->ki_p->ki_rusage.ru_stime.tv_sec;
+   psecs = k->ki_p->ki_rusage.ru_stime.tv_usec;
+   if (sumrusage) {
+   secs += k->ki_p->ki_childstime.tv_sec;
+   psecs += k->ki_p->ki_childstime.tv_usec;
+   }
+   /*
+* round and scale to 100's
+*/
+   psecs = (psecs + 5000) / 1;
+   secs += psecs / 100;
+   psecs = psecs % 100;
+   }
+   (void)snprintf(obuff, sizeof(obuff), "%3ld:%02ld%c%02ld",
+   secs / 60, secs % 60, decimal_point, psecs);
+   (void)printf("%*s", v->width, obuff);
+}
+
+void
+usertime(KINFO *k, VARENT *ve)
+{
+   VAR *v;
+   long secs;
+   long psecs; /* "parts" of a second. first micro, then centi */
+   char obuff[128];
+   static char decimal_point;
+
+   if (decimal_point == '\0')
+   decimal_point = localeconv()->decimal_point[0];
+   v = ve->var;
+   if (!k->ki_valid) {
+   secs = 0;
+   psecs = 0;
+   } else {
+   secs = k->ki_p->ki

Re: CPU user/kernel time given the PID

2009-03-08 Thread David Wolfskill
On Sun, Mar 08, 2009 at 08:33:27PM -0400, Jay Loden wrote:
> Oliver Fromme wrote:
> > ps(1) and top(1) both use ki_pctcpu, see the getpcpu()
> > function in src/bin/ps/print.c and format_next_process()
> > in src/usr.bin/top/machine.c
> 
> Hi Oliver, thanks for the reply. I noticed the same after some digging through
> the source code for ps and top. While CPU usage % is a useful number also, I 
> was
> hoping to be able to get CPU time(s). Possibly that information simply isn't
> available on FreeBSD like it is for other OSes.

Have you checked to see if you can make use of the information provided
by procfs(5)?  In particular, I note:

...
 status  The process status.  This file is read-only and returns a single
 line containing multiple space-separated fields as follows:

 o   command name
 o   process id
...
 o   the process start time in seconds and microseconds, comma
 separated.
 o   the user time in seconds and microseconds, comma separated.
 o   the system time in seconds and microseconds, comma separated.
 o   the wait channel message


Thus, on my laptop, I see:

g1-35(6.4-S)[1] cat /proc/`pgrep firefox-bin`/status
firefox-bin 1735 1730 1549 1454 - noflags 1236526247,367664 3289,390208 
477,843140 -kse-  1001 1001 1001,1001,1001,0,20,68,69,1004 -
g1-35(6.4-S)[2] 

So above-listed items would be:

* firefox-bin
* 1735
...
* 1236526247,367664
* 3289,390208
* 477,843140
* -kse-

* -kse-


Granted, not every machine will necessarily have PROCFS in the
kernel configuration, but it is in GENERIC.

> ...

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


pgpuSnkm6qsU3.pgp
Description: PGP signature