Re: Make process title - % complete
Quoting Alex Kozlov s...@rm-rf.kiev.ua: On Mon, Oct 19, 2009 at 05:51:42PM +0200, Ivan Voras wrote: 2009/10/19 Alex Kozlov s...@rm-rf.kiev.ua: On Mon, Oct 19, 2009 at 04:35:08PM +0200, Ivan Voras wrote: if nobody objects, I'll commit it :) I seem to recall that setproctitle() is quite expensive to call; perhaps it would make sense offer a flag to prevent make(1) from calling it? [1] Anyway, the feature looks nice! I'd like to have it... [1] I'm unsure how expensive it is compared to fork(1)-ing etc; I'd expect it's negligable but who knows... The loop it's called in is not processed bazillion times per second (though it *is* called surprisingly often; small, fast jobs can result in somewhere in the order of magnitude of 100 iterations per second on a fast CPU). As you said - I expect it's negligable compared to fork() and the work jobs themselves do. How about add this statistic to make info handler? You mean SIGINFO? Yes Using SIGINFO sounds nice, but make produces so much output that normally you won't see the result because it is scrolled up just after sending the signal. pgp3asCWYW1Au.pgp Description: PGP Digital Signature
FreeBSD DAQ Card Facility [DCF]
Finally I've updated the documentation part from the FreeBSD DCF project site: http://freebsd-dcf.sourceforge.net/docu.html I hope that helps to get a better overview. Thanks, Manuel Gebele -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ 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: FreeBSD DAQ Card Facility [DCF]
Manuel Gebele forens...@gmx.de writes: Finally I've updated the documentation part from the FreeBSD DCF project site: What made you choose the name DCF? DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Make process title - % complete
On Tue, Oct 20, 2009 at 10:07:07AM +0200, Lars Engels wrote: Quoting Alex Kozlov s...@rm-rf.kiev.ua: On Mon, Oct 19, 2009 at 05:51:42PM +0200, Ivan Voras wrote: 2009/10/19 Alex Kozlov s...@rm-rf.kiev.ua: On Mon, Oct 19, 2009 at 04:35:08PM +0200, Ivan Voras wrote: if nobody objects, I'll commit it :) I seem to recall that setproctitle() is quite expensive to call; perhaps it would make sense offer a flag to prevent make(1) from calling it? [1] Anyway, the feature looks nice! I'd like to have it... [1] I'm unsure how expensive it is compared to fork(1)-ing etc; I'd expect it's negligable but who knows... The loop it's called in is not processed bazillion times per second (though it *is* called surprisingly often; small, fast jobs can result in somewhere in the order of magnitude of 100 iterations per second on a fast CPU). As you said - I expect it's negligable compared to fork() and the work jobs themselves do. How about add this statistic to make info handler? You mean SIGINFO? Yes Using SIGINFO sounds nice, but make produces so much output that normally you won't see the result because it is scrolled up just after sending the signal. Of course ps or top output much more convenient, but if setproctitle so expencive and will be called so often, then SIGINFO may be good compromise. -- Adios ___ 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: Make process title - % complete
Alex Kozlov wrote:
Of course ps or top output much more convenient, but if setproctitle so
expencive and will be called so often, then SIGINFO may be good
compromise.
Regarding speed of setproctitle(), here are some microbenchmark results
from the attached test source:
getpid: 3661124.75 iterations/s
setproctitle: 591357.56 iterations/s
Meaning, setprocitle() is around 6 times more expensive than getpid(),
meaning it can only be pulled off nearly 600,000 calls/s on a 2.3 GHz
Core 2 CPU.
I really want to be enlightened about how it could affect wallclock time
in make(1).
#include sys/time.h
#include stdlib.h
#include stdio.h
#include string.h
#include unistd.h
#define NITER 1e7
double now() {
struct timeval tp;
gettimeofday(tp, NULL);
return tp.tv_sec + (double)tp.tv_usec / 1e6f;
}
int main() {
double t1, t2, t3;
int i;
t1 = now();
for (i = 0; i NITER; i++)
getpid();
t2 = now() - t1;
printf(getpid: %0.2f iterations/s\n, (float)(NITER/t2));
t1 = now();
for (i = 0; i NITER; i++)
setproctitle(t%d, i);
t3 = now() - t1;
printf(setproctitle: %0.2f iterations/s\n, (float)(NITER/t3));
}
___
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: Make process title - % complete
Hi, On Mon, Oct 19, 2009 at 4:40 PM, Ivan Voras ivo...@freebsd.org wrote: Ivan Voras wrote: I have a small patch that makes make display percentage complete in process title, which can be retrieved in top in the form of: 71466 root 1 76 0 7008K 5696K select 0 0:00 0.00% make: 95% (55 more targets out of 1360) (make) Also: is there someone here more familiar with make who can tell me if the current top level target (i.e. the one taken from the command line) is kept track of somewhere? For example clean in make clean install. gmake does show the nesting level in its output and indeed it's a valuable information if setproctitle is to be used... gmake appears to use a MAKELEVEL environment variable to keep track in between parent/child runs. I see a similar mechanism in our make (using the __MKLVL__ environment variable) but it's restricted only to the check_make_level() function that is checking the nesting level, thus no global variable is available to use. Regards, Adrian Penisoara EnterpriseBSD.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
FreeBSD DAQ Card Facility [DCF]
The acronym stands for DAQ (Data AcQuisition) Card Facility MG -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ 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
FreeBSD DAQ Card Facility [DCF]
If you take a look at my site on sourceforge you should know why that acronym. But I'm flexible, so maybe there is a better name for that. Thanks, MG -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ 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: Make process title - % complete
On Tue, 2009-10-20 at 14:42 +0200, Ivan Voras wrote:
Alex Kozlov wrote:
Of course ps or top output much more convenient, but if setproctitle so
expencive and will be called so often, then SIGINFO may be good
compromise.
Regarding speed of setproctitle(), here are some microbenchmark results
from the attached test source:
getpid: 3661124.75 iterations/s
setproctitle: 591357.56 iterations/s
Meaning, setprocitle() is around 6 times more expensive than getpid(),
meaning it can only be pulled off nearly 600,000 calls/s on a 2.3 GHz
Core 2 CPU.
I really want to be enlightened about how it could affect wallclock time
in make(1).
What is the relative difference in buildworld time with and without?
robert.
#include sys/time.h
#include stdlib.h
#include stdio.h
#include string.h
#include unistd.h
#define NITER 1e7
double now() {
struct timeval tp;
gettimeofday(tp, NULL);
return tp.tv_sec + (double)tp.tv_usec / 1e6f;
}
int main() {
double t1, t2, t3;
int i;
t1 = now();
for (i = 0; i NITER; i++)
getpid();
t2 = now() - t1;
printf(getpid: %0.2f iterations/s\n, (float)(NITER/t2));
t1 = now();
for (i = 0; i NITER; i++)
setproctitle(t%d, i);
t3 = now() - t1;
printf(setproctitle: %0.2f iterations/s\n, (float)(NITER/t3));
}
___
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
--
Robert Noland rnol...@freebsd.org
FreeBSD
___
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: FreeBSD DAQ Card Facility [DCF]
Manuel Gebele forens...@gmx.de writes: The acronym stands for DAQ (Data AcQuisition) Card Facility [...] If you take a look at my site on sourceforge you should know why that acronym. But I'm flexible, so maybe there is a better name for that. First, when you answer a question on a mailing list, it is customary to use your MUA's reply function and to quote the question. Otherwise, there is nothing to tie the answer to the question, and nobody will understand anything, except possibly the person who asked the question in the first place. It is also customary to answer once, not twice. That being taken care of - the reason I asked is that to me (and to many other time boffins and NTP fundamentalists), DCF is a longwave radio station in Frankfurt which is commonly used as an external reference for NTP servers. I would have just called it DAQ, which as you know is an established abbreviation for Data Acquisition. The card part is meaningless; FreeBSD runs on plenty of hardware with integrated DAQ facilities, such as the Soekris, or pretty much anything built around a MIPS or ARM or (soon) AVR32 microcontroller. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: FreeBSD DAQ Card Facility [DCF]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Oct 2009 15:24+0200, Dag-Erling Smørgrav wrote: Manuel Gebele forens...@gmx.de writes: The acronym stands for DAQ (Data AcQuisition) Card Facility [...] If you take a look at my site on sourceforge you should know why that acronym. But I'm flexible, so maybe there is a better name for that. [...] That being taken care of - the reason I asked is that to me (and to many other time boffins and NTP fundamentalists), DCF is a longwave radio station in Frankfurt which is commonly used as an external reference for NTP servers. The call sign is really DCF77. Trond. - -- - -- Trond Endrestøl | trond.endres...@fagskolen.gjovik.no ACM, NAS, NUUG, SAGE, USENIX |FreeBSD 7.2-STABLE Alpine 2.00 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkrdvDEACgkQbYWZalUoElugNACbBgWAVm2EUd6QRE7pA07oVrP6 ldcAn1YmYbFfpdu/z+bIT1eyj0cd1KiG =Gjqa -END PGP SIGNATURE-___ 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: Make process title - % complete
On Tue, Oct 20, 2009 at 02:42:17PM +0200, Ivan Voras wrote: Alex Kozlov wrote: Of course ps or top output much more convenient, but if setproctitle so expencive and will be called so often, then SIGINFO may be good compromise. Regarding speed of setproctitle(), here are some microbenchmark results from the attached test source: getpid: 3661124.75 iterations/s setproctitle: 591357.56 iterations/s Meaning, setprocitle() is around 6 times more expensive than getpid(), meaning it can only be pulled off nearly 600,000 calls/s on a 2.3 GHz Core 2 CPU. I really want to be enlightened about how it could affect wallclock time in make(1). make universe few times with and without patch? -- Adios ___ 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: FreeBSD DAQ Card Facility [DCF]
Trond Endrestøl trond.endres...@fagskolen.gjovik.no writes: The call sign is really DCF77. ...and it's not really in Frankfurt. True, but irrelevant. See RFC2030. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Make process title - % complete
On Tue, Oct 20, 2009 at 02:42:17PM +0200, Ivan Voras wrote: Alex Kozlov wrote: Of course ps or top output much more convenient, but if setproctitle so expencive and will be called so often, then SIGINFO may be good compromise. Regarding speed of setproctitle(), here are some microbenchmark results from the attached test source: getpid: 3661124.75 iterations/s setproctitle: 591357.56 iterations/s Meaning, setprocitle() is around 6 times more expensive than getpid(), meaning it can only be pulled off nearly 600,000 calls/s on a 2.3 GHz Core 2 CPU. what about contention? setproctitle() is an sysctl so it will prevent other sysctl's from working when being executed.. ___ 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: Make process title - % complete
2009/10/20 Roman Divacky rdiva...@freebsd.org: On Tue, Oct 20, 2009 at 02:42:17PM +0200, Ivan Voras wrote: Alex Kozlov wrote: Of course ps or top output much more convenient, but if setproctitle so expencive and will be called so often, then SIGINFO may be good compromise. Regarding speed of setproctitle(), here are some microbenchmark results from the attached test source: getpid: 3661124.75 iterations/s setproctitle: 591357.56 iterations/s Meaning, setprocitle() is around 6 times more expensive than getpid(), meaning it can only be pulled off nearly 600,000 calls/s on a 2.3 GHz Core 2 CPU. what about contention? setproctitle() is an sysctl so it will prevent other sysctl's from working when being executed.. Others sysctls... for that particular process (since it modifies process-global data) which happens to be single-threaded :P ___ 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: Make process title - % complete
On Mon, 19 Oct 2009 17:51:42 +0200, Ivan Voras ivo...@freebsd.org wrote: 2009/10/19 Alex Kozlov s...@rm-rf.kiev.ua: How about add this statistic to make info handler? You mean SIGINFO? Yes, that's the ``info handler''. While printing something on SINGINFO arrival is a nice idea, it may not be extremely useful for make(1). With dd(1) this is very useful to see, but with long-running make jobs that write tons of output to stderr any information from SIGINFO may be lost in the noise. ___ 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: Make process title - % complete
Giorgos Keramidas wrote: On Mon, 19 Oct 2009 17:51:42 +0200, Ivan Voras ivo...@freebsd.org wrote: 2009/10/19 Alex Kozlov s...@rm-rf.kiev.ua: How about add this statistic to make info handler? You mean SIGINFO? Yes, that's the ``info handler''. While printing something on SINGINFO arrival is a nice idea, it may not be extremely useful for make(1). With dd(1) this is very useful to see, but with long-running make jobs that write tons of output to stderr any information from SIGINFO may be lost in the noise. ___ 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 The SIGINFO handler could be made to put the make process to sleep for, say, a second to give the user some time to read the statistics, but I'm sure there are lots of objections to be made to that, too. -Boris ___ 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: Make process title - % complete
On Monday 19 October 2009 16:08:06 Rink Springer wrote: Hi Ivan, On Mon, Oct 19, 2009 at 03:52:30PM +0200, Ivan Voras wrote: if nobody objects, I'll commit it :) I seem to recall that setproctitle() is quite expensive to call; perhaps it would make sense offer a flag to prevent make(1) from calling it? [1] Just rate-limit the setproctitle() call to once/sec or once/percentage-step and be done with it. I must say that trying it out on a kernel build didn't proof too useful as the targets have vastly different runtimes, but I think it's a good addition nonetheless. So please, go for it Ivan. Anyway, the feature looks nice! I'd like to have it... [1] I'm unsure how expensive it is compared to fork(1)-ing etc; I'd expect it's negligable but who knows... -- /\ Best regards, | mla...@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mla...@efnet / \ ASCII Ribbon Campaign | Against HTML Mail and News ___ 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: Make process title - % complete
On Tue, 20 Oct 2009 20:28:40 -0400, Boris Kochergin sp...@acm.poly.edu wrote: Giorgos Keramidas wrote: On Mon, 19 Oct 2009 17:51:42 +0200, Ivan Voras ivo...@freebsd.org wrote: 2009/10/19 Alex Kozlov s...@rm-rf.kiev.ua: How about add this statistic to make info handler? You mean SIGINFO? Yes, that's the ``info handler''. While printing something on SINGINFO arrival is a nice idea, it may not be extremely useful for make(1). With dd(1) this is very useful to see, but with long-running make jobs that write tons of output to stderr any information from SIGINFO may be lost in the noise. The SIGINFO handler could be made to put the make process to sleep for, say, a second to give the user some time to read the statistics, but I'm sure there are lots of objections to be made to that, too. That would be bad, indeed. David Wolfskill has emailed me, in the meantime, that it's probably ok to `lose' SIGINFO output in the noise of build output, as long as it is easy to grep for it. So I still like the idea, but without a delay please :) pgpF8p6C0GJbo.pgp Description: PGP signature
mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED
hi there,
just a little mmap(2) related question. running the following code causes a
segfault:
mmap( (void*)0x1000, 0x80047000, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 );
while the following doesn't:
mmap( (void*)0x1000, 0x, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 );
is this a known problem? seems reproducible on all branches.
cheers
alex
#include sys/mman.h
#include stdlib.h
#include stdio.h
int main()
{
printf(mmap: %p\n, mmap( (void*)0x1000, 0x, PROT_NONE,
MAP_ANON|MAP_FIXED, -1, 0 ));
printf(mmap: %p\n, mmap( (void*)0x1000, 0x80047000, PROT_NONE,
MAP_ANON|MAP_FIXED, -1, 0 ));
return 0;
}
___
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: mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED
On Wed, 21 Oct 2009, Alexander Best wrote: hi there, This is on a 32-bit platform I take it? just a little mmap(2) related question. running the following code causes a segfault: mmap( (void*)0x1000, 0x80047000, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 ); I don't doubt it. You mapped over a big chunk of your address space with memory that's inaccessible (PROT_NONE). This probably includes your program's code. So when the mmap call returns from the kernel and tries to execute the next instruction of your program, it finds that the instruction pointer is pointing to inaccessible memory. Result: segfault. This is quite normal. What are you actually trying to accomplish with this? while the following doesn't: mmap( (void*)0x1000, 0x, PROT_NONE, MAP_ANON|MAP_FIXED, -1, 0 ); Did you check whether the mmap actually succeeded? I bet it didn't. You have a length that isn't a multiple of the page size and wraps around 32 bits. I bet you got an EINVAL, and the mmap call didn't actually do anything. is this a known problem? seems reproducible on all branches. Not a problem at all, I suspect. -- Nate Eldredge n...@thatsmathematics.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
