Re: Is pthread_cond_signal(3) man page correct?
On 02/27/2011 18:00, David Xu wrote: I think in normal case, pthread_cond_signal will wake up one thread, but other events for example, UNIX signal and fork() may interrupt a thread sleeping in kernel, and cause pthread_cond_wait to return to userland, this is called spurious wakeup, and other events, I can not think of yet, but I believe they exist. Does this mean that pthread_cond_signal can also return EINTR? This isn't in pthread_cond_signal(3) either. Is this the case that all system calls should be assumed to be able to return EINTR or only those that have EINTR in their man pages? Yuri ___ 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"
usertime and systime
Hi, without procfs, there is a way to get usertime and systime from a running process? Thiago ___ 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: usertime and systime
On Wed, 2011-03-16 at 14:02 -0300, Thiago Damas wrote:
> Hi,
> without procfs, there is a way to get usertime and systime from a
> running process?
>
Maybe:
ps axwwwo pid,time,command
According to ps(1):
time ... "accumulated cpu time, user + system"
Unfortunately, I'm not able to find a way to get user time separate from
system time ("time" -- aka "cputime" -- only gives combined "user" plus
"system" time).
> Thiago
> ___
> 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"
--
--
Cheers,
Devin Teske
-> FUN STUFF <-
-BEGIN GEEK CODE BLOCK-
Version 3.12
GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L
$ E-
W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b
+>++ DI+
D+(++) G++ e> h r+++ z+++
--END GEEK CODE BLOCK--
Learn about the "Geek Code": http://www.geekcode.com/
-> LEGAL DISCLAIMER <-
This message contains confidential and proprietary information
of the sender, and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person is strictly prohibited. If you have received this
message in error, please notify the e-mail sender immediately,
and delete the original message without making a copy.
-> END TRANSMISSION <-
___
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: usertime and systime
In the last episode (Mar 16), Thiago Damas said:
> Hi,
> without procfs, there is a way to get usertime and systime from a
> running process?
Try applying the attached patch to ps. I've had it for a while but never
submitted a PR.
Heh. I've had it for a very long time.
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html
--
Dan Nelson
dnel...@allantgroup.com
Index: ps.1
===
--- ps.1 (revision 219700)
+++ ps.1 (working copy)
@@ -587,6 +587,8 @@ symbolic process state (alias
saved gid from a setgid executable
.It Cm svuid
saved UID from a setuid executable
+.It Cm systime
+accumulated system CPU time
.It Cm tdaddr
thread address
.It Cm tdev
@@ -617,6 +619,8 @@ scheduling priority on return from system call (al
.Cm usrpri )
.It Cm user
user name (from UID)
+.It Cm usertime
+accumulated user CPU time
.It Cm vsz
virtual size in Kbytes (alias
.Cm vsize )
Index: keyword.c
===
--- keyword.c (revision 219700)
+++ keyword.c (working copy)
@@ -186,6 +186,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},
{"tdaddr", "TDADDR", NULL, 0, kvar, NULL, sizeof(void *) * 2,
KOFF(ki_tdaddr), KPTR, "lx", 0},
{"tdev", "TDEV", NULL, 0, tdev, NULL, 5, 0, CHAR, NULL, 0},
@@ -207,6 +208,7 @@ static VAR var[] = {
KOFF(ki_paddr), KPTR, "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: extern.h
===
--- extern.h (revision 219700)
+++ extern.h (working copy)
@@ -79,12 +79,14 @@ int s_uname(KINFO *);
void showkey(void);
void started(KINFO *, VARENT *);
void state(KINFO *, VARENT *);
+void systime(KINFO *, VARENT *);
void tdev(KINFO *, VARENT *);
void tdnam(KINFO *, VARENT *);
void tname(KINFO *, VARENT *);
void ucomm(KINFO *, VARENT *);
void uname(KINFO *, VARENT *);
void upr(KINFO *, VARENT *);
+void usertime(KINFO *, VARENT *);
void vsize(KINFO *, VARENT *);
void wchan(KINFO *, VARENT *);
__END_DECLS
Index: print.c
===
--- print.c (revision 219700)
+++ print.c (working copy)
@@ -588,6 +588,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_rusage.ru_utime.tv_sec;
+ psecs = k->ki_p->ki_rusage.ru_utime.tv_usec;
+ if (sumrusage) {
+ secs += k->ki_p->ki_childutime.tv_sec;
+ psecs += k->ki_p->ki_childutime.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
elapsed(KINFO *k, VARENT *ve)
{
VAR *v;
___
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: usertime and systime
Hi, the patch worked for me, using RELENG_8_2 Very thanks! Thiago 2011/3/16 Dan Nelson : > In the last episode (Mar 16), Thiago Damas said: >> Hi, >> without procfs, there is a way to get usertime and systime from a >> running process? > > Try applying the attached patch to ps. I've had it for a while but never > submitted a PR. > > Heh. I've had it for a very long time. > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html > > -- > 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"
Re: usertime and systime
On Wed, 2011-03-16 at 12:56 -0500, Dan Nelson wrote: > In the last episode (Mar 16), Thiago Damas said: > > Hi, > > without procfs, there is a way to get usertime and systime from a > > running process? > > Try applying the attached patch to ps. I've had it for a while but never > submitted a PR. > > Heh. I've had it for a very long time. > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html +1 useful. I'd like to see this committed. > > ___ > 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" -- Cheers, Devin Teske -> FUN STUFF <- -BEGIN GEEK CODE BLOCK- Version 3.12 GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L $ E- W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b +>++ DI+ D+(++) G++ e> h r+++ z+++ --END GEEK CODE BLOCK-- Learn about the "Geek Code": http://www.geekcode.com/ -> LEGAL DISCLAIMER <- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. -> END TRANSMISSION <- ___ 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: usertime and systime
On Wed, Mar 16, 2011 at 12:56:14PM -0500, Dan Nelson wrote:
> In the last episode (Mar 16), Thiago Damas said:
> > Hi,
> > without procfs, there is a way to get usertime and systime from a
> > running process?
>
> Try applying the attached patch to ps. I've had it for a while but never
> submitted a PR.
>
> Heh. I've had it for a very long time.
> http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html
Yes, apparently, this is often requested feature.
I dislike the copying of the existing code, sincere up to the comment
that is not quite relevant (about interrupts in systime). I slightly
reorganized the patch to reduce the copy/paste part of it.
Do you have comments ?
diff --git a/bin/ps/extern.h b/bin/ps/extern.h
index faeeb19..eb1ede6 100644
--- a/bin/ps/extern.h
+++ b/bin/ps/extern.h
@@ -81,12 +81,14 @@ int s_uname(KINFO *);
voidshowkey(void);
voidstarted(KINFO *, VARENT *);
voidstate(KINFO *, VARENT *);
+voidsystime(KINFO *, VARENT *);
voidtdev(KINFO *, VARENT *);
voidtdnam(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
diff --git a/bin/ps/keyword.c b/bin/ps/keyword.c
index 3bcc23b..09eb756 100644
--- a/bin/ps/keyword.c
+++ b/bin/ps/keyword.c
@@ -189,6 +189,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},
{"tdaddr", "TDADDR", NULL, 0, kvar, NULL, sizeof(void *) * 2,
KOFF(ki_tdaddr), KPTR, "lx", 0},
{"tdev", "TDEV", NULL, 0, tdev, NULL, 5, 0, CHAR, NULL, 0},
@@ -210,6 +211,8 @@ static VAR var[] = {
KOFF(ki_paddr), KPTR, "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, 6, 0, CHAR, NULL, 0},
diff --git a/bin/ps/print.c b/bin/ps/print.c
index 46b979b..253793a 100644
--- a/bin/ps/print.c
+++ b/bin/ps/print.c
@@ -550,12 +550,11 @@ vsize(KINFO *k, VARENT *ve)
(void)printf("%*lu", v->width, (u_long)(k->ki_p->ki_size / 1024));
}
-void
-cputime(KINFO *k, VARENT *ve)
+static void
+printtime(KINFO *k, VARENT *ve, long secs, long psecs)
+/* psecs is "parts" of a second. first micro, then centi */
{
VAR *v;
- long secs;
- long psecs; /* "parts" of a second. first micro, then centi */
char obuff[128];
static char decimal_point;
@@ -566,20 +565,7 @@ cputime(KINFO *k, VARENT *ve)
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_runtime / 100;
- psecs = k->ki_p->ki_runtime % 100;
- if (sumrusage) {
- secs += k->ki_p->ki_childtime.tv_sec;
- psecs += k->ki_p->ki_childtime.tv_usec;
- }
- /*
-* round and scale to 100's
-*/
+ /* round and scale to 100's */
psecs = (psecs + 5000) / 1;
secs += psecs / 100;
psecs = psecs % 100;
@@ -590,6 +576,53 @@ cputime(KINFO *k, VARENT *ve)
}
void
+cputime(KINFO *k, VARENT *ve)
+{
+ long secs, psecs;
+
+ /*
+* 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_runtime / 100;
+ psecs = k->ki_p->ki_runtime % 100;
+ if (sumrusage) {
+ secs += k->ki_p->ki_childtime.tv_sec;
+ psecs += k->ki_p->ki_childtime.tv_usec;
+ }
+ printtime(k, ve, secs, psecs);
+}
+
+void
+systime(KINFO *k, VARENT *ve)
+{
+ long secs, psecs;
+
+ 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;
+ }
+ printtime(k, ve, secs, psecs);
+}
+
+void
+usertime(KINFO *k, VARENT *ve)
+{
+ long secs, psecs;
+
+ secs = k->ki_p->ki_rusage.ru_uti
Re: usertime and systime
On Wed, 16 Mar 2011 14:42:22 -0500, Devin Teske wrote: +1 useful. I'd like to see this committed. Agreed. ___ 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: usertime and systime
In the last episode (Mar 16), Kostik Belousov said: > On Wed, Mar 16, 2011 at 12:56:14PM -0500, Dan Nelson wrote: > > In the last episode (Mar 16), Thiago Damas said: > > > Hi, > > > without procfs, there is a way to get usertime and systime from a > > > running process? > > > > Try applying the attached patch to ps. I've had it for a while but > > never submitted a PR. > > > > Heh. I've had it for a very long time. > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/027918.html > > Yes, apparently, this is often requested feature. > > I dislike the copying of the existing code, sincere up to the comment that > is not quite relevant (about interrupts in systime). I slightly > reorganized the patch to reduce the copy/paste part of it. > > Do you have comments ? I like it. -- 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"
Re: Is pthread_cond_signal(3) man page correct?
On 2011/03/16 23:23, Yuri wrote: > On 02/27/2011 18:00, David Xu wrote: >> I think in normal case, pthread_cond_signal will wake up one thread, >> but other events for example, UNIX signal and fork() may interrupt >> a thread sleeping in kernel, and cause pthread_cond_wait to return >> to userland, this is called spurious wakeup, and other events, I >> can not think of yet, but I believe they exist. >> > > Does this mean that pthread_cond_signal can also return EINTR? This > isn't in pthread_cond_signal(3) either. > No, it will return zero, returning EINTR is not allowed. > Is this the case that all system calls should be assumed to be able to > return EINTR or only those that have EINTR in their man pages? > > Yuri > ___ 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: Is pthread_cond_signal(3) man page correct?
On Wed, Mar 16, 2011 at 6:54 PM, David Xu wrote: > On 2011/03/16 23:23, Yuri wrote: >> On 02/27/2011 18:00, David Xu wrote: >>> I think in normal case, pthread_cond_signal will wake up one thread, >>> but other events for example, UNIX signal and fork() may interrupt >>> a thread sleeping in kernel, and cause pthread_cond_wait to return >>> to userland, this is called spurious wakeup, and other events, I >>> can not think of yet, but I believe they exist. >>> >> >> Does this mean that pthread_cond_signal can also return EINTR? This >> isn't in pthread_cond_signal(3) either. >> > > No, it will return zero, returning EINTR is not allowed. Adding some more context by adding the appropriate POSIX spec material... RETURN VALUE If successful, the pthread_cond_broadcast() and pthread_cond_signal() functions shall return zero; otherwise, an error number shall be returned to indicate the error. ERRORS The pthread_cond_broadcast() and pthread_cond_signal() function may fail if: [EINVAL] The value cond does not refer to an initialized condition variable. These functions shall not return an error code of [EINTR]. So yes, EINTR not being allowed is by design and this backs up what davidxu@ is stating above. Our manpage just doesn't explicitly call this requirement out, unlike a Linux manpage I dug up and the OpenGroup manpage. >> Is this the case that all system calls should be assumed to be able to >> return EINTR or only those that have EINTR in their man pages? Thanks, -Garrett ___ 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"
