Re: Make process title - % complete
Hi, On Wed, Oct 21, 2009 at 3:11 AM, Max Laier wrote: > 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. Rather try to setproctitle() in the same make process every second with a one second initial delay (so that short lived make processes won't be bogged down by this expensive call). And preferentially do the timing check after returning from exec() of a child make. This way the stats won't be "perturbed" by the short lived make's and only one make process will call setproctitle() at any time (except when running "make -j" ?). > > 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. > If you implement it, please use a control mechanism like, say, an environment variable MAKE_TRACK_PROGRESS, which, for performance and POLA sake, might default to disabled (including when environment is not defined). My 5cents, 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"
Re: FreeBSD DAQ Card Facility [DCF]
"Manuel Gebele" writes: > Dag-Erling Smørgrav writes: > > I would have just called it DAQ, which as you know is an established > > abbreviation for "Data Acquisition". [...] > I have no objection to that naming. Maybe I should call it just > ``FreeBSD DAQ Facility'' (FDF). I don't understand why it has to be so complicated. What's wrong with just "DAQ"? (not that any of this really matters in the big picture...) 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]
on 21/10/2009 12:20 Dag-Erling Smørgrav said the following: > I don't understand why it has to be so complicated. > What's wrong with just "DAQ"? [...] What please is complicated in ``FreeBSD DAQ Facility''? Whats about KLD ``Dynamic Kernel Linker Facility''? BTW, if I send you a private email and you answer to the list, it would be great if you could put in all of the email content: on 20/10/2009 15:24 Dag-Erling Smørgrav said the following: > 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. [...] Oh, my mistake sorry for that. I'm not an ML expert at all, and that was my first message to a list (in that 'reply' context). > 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. DCF(77) is in the near of "Frankfurt am Main (not Oder)" thats true. On the other side, there are so many definitions for DCF; Data Capture Facility, Data Compression Facility and so on (look at http://www.acronymfinder.com/DCF.html). We get problems if we open ``/dev/dcf77'' --maybe =) Whats about the MSF station in Rugby --england? MSF - Microsoft Solutions Framework (please no jokes about $MS) MSF - Metasploit Framework Whats about code with an 'VLF' acronym =) ? --better not But I understand your point, maybe we should exclude any misunderstandings. > I would have just called it DAQ, which as you know is > an established abbreviation for "Data Acquisition". [...] I have no objection to that naming. Maybe I should call it just ``FreeBSD DAQ Facility'' (FDF). 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: mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED
Nate Eldredge schrieb am 2009-10-21: > On Wed, 21 Oct 2009, Alexander Best wrote: > >hi there, > This is on a 32-bit platform I take it? yes. > >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? this code serves only one purpose: to trigger a segfault. i don't use the code for any other purpose. i was under the impression that mmap() should either succeed or fail (tertium non datur). mmap's manual doesn't say anything about mmap() causing segfaults. from your description of the problem i don't think there's a quick fix to it. so it might be a good idea to add this case to the mmap(2) bug section. > >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. > -- indeed the mmap() call fails with EINVAL but it doesn't segfault. to make this clear: i don't expect either one of the mmap() calls to succeed. > 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"
Re: mmap(2) segaults with certain len values and MAP_ANON|MAP_FIXED
On Wed, 21 Oct 2009, Alexander Best wrote: this code serves only one purpose: to trigger a segfault. i don't use the code for any other purpose. i was under the impression that mmap() should either succeed or fail (tertium non datur). mmap's manual doesn't say anything about mmap() causing segfaults. Have you tried ktracing the application? I think you'll find that mmap(2) system call succeeded fine, and that the segfault comes from attempting to execute the address in libc on return to userspace, as a result of libc not being at that address anymore (since you removed its mapping). You can use procstat -v to inspect address space use by processes, but as a general rule you don't want to pass anything other than an address of 0x0 to mmap(2) unless you're very carefully managing the address space of the process. Many userspace libraries are involved in using that address space, but especially the runtime linker which begins execution in userspace when a binary is started. Robert N M Watson Computer Laboratory University of Cambridge ___ 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
Robert Watson schrieb am 2009-10-21: > On Wed, 21 Oct 2009, Alexander Best wrote: > >this code serves only one purpose: to trigger a segfault. i don't > >use the code for any other purpose. i was under the impression that > >mmap() should either succeed or fail (tertium non datur). mmap's > >manual doesn't say anything about mmap() causing segfaults. > Have you tried ktracing the application? I think you'll find that > mmap(2) system call succeeded fine, and that the segfault comes from > attempting to execute the address in libc on return to userspace, as > a result of libc not being at that address anymore (since you > removed its mapping). You can use procstat -v to inspect address > space use by processes, but as a general rule you don't want to pass > anything other than an address of 0x0 to mmap(2) unless you're very > carefully managing the address space of the process. Many userspace > libraries are involved in using that address space, but especially > the runtime linker which begins execution in userspace when a binary > is started. > Robert N M Watson > Computer Laboratory > University of Cambridge you're right. this kdump shows that the segfault isn't being caused by the mmap() call: 88343 mmap_test CALL mmap(0x1000,0x80047000,PROT_NONE,MAP_FIXED|MAP_ANON,0x,0,0) 88343 mmap_test RET mmap 4096/0x1000 88343 mmap_test PSIG SIGSEGV SIG_DFL 88343 mmap_test NAMI "mmap_test.core" thanks for clearing things up. however i stil think mentioning this situation in the mmap(2) manual (maybe in section MAP_FIXED) would be a good idea. cheers. alex ___ 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"
mmap(2) with MAP_ANON honouring offset although it shouldn't
although the mmap(2) manual states in section MAP_ANON:
"The offset argument is ignored."
this doesn't seem to be true. running
printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1,
0x12345678));
and
printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1, 0));
produces different outputs. i've attached a patch to solve the problem. the
patch is similar to the one proposed in this PR, but should apply cleanly to
CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258
cheers.
alex
--- src/sys/vm/vm_mmap.c2009-10-21 04:13:24.0 +0200
+++ src/sys/vm/vm_mmap.c2009-10-21 04:13:43.0 +0200
@@ -245,15 +245,18 @@
}
/*
-* Align the file position to a page boundary,
-* and save its page offset component.
+* Unless the MAP_ANON flag is set, align the file position
+* to a page boundary and save its page offset component.
*/
- pageoff = (pos & PAGE_MASK);
- pos -= pageoff;
-
- /* Adjust size for rounding (on both ends). */
- size += pageoff;/* low end... */
- size = (vm_size_t) round_page(size);/* hi end */
+ if (flags & MAP_ANON) {
+ pageoff = pos = 0;
+ } else {
+ pageoff = (pos & PAGE_MASK);
+ pos -= pageoff;
+ /* Adjust size for rounding (on both ends). */
+ size += pageoff;/* low end... */
+ size = (vm_size_t) round_page(size);/* hi end */
+ }
/*
* Check for illegal addresses. Watch out for address wrap... Note
@@ -300,7 +303,6 @@
handle = NULL;
handle_type = OBJT_DEFAULT;
maxprot = VM_PROT_ALL;
- pos = 0;
} else {
/*
* Mapping file, get fp for validation and
___
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" writes: > BTW, if I send you a private email and you answer to the list, I answered to an email you sent to the list. 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"
multi-seg bus_dmamem_alloc?
Hi everyone, It seems like there are starting to be some drivers that need to allocate large chunks of DMA-able memory, and since bus_dmamem_alloc() on most architectures is always physically contiguous, it may not work for them. It seems like we could use the new sglist routines to help us here: --Define 2 new functions: int bus_dmamem_alloc_sglist(bus_dma_tag_t dmat, size_t size, struct sglist *sg, int flags, bus_dmamap_t *mapp) void bus_dmamem_free_sglist(bus_dma_tag_t dmat, struct sglist *sg, bus_dmamap_t map); --For sparc64 (or anywhere else we want to use an IOMMU): malloc() the buffer, feed it to sglist_build(), program the IOMMU to meet the constraints in dmat--Isn't this what we already do for sparc64, minus the sglist part? --For direct-mapped architectures: If the constraints in dmat are lenient enough, do malloc() and sglist_build(). Otherwise, do contigmalloc(M_NOWAIT) in a loop, in which we try to allocate as much of the buffer as possible. Anytime an allocation fails, we divide the allocation size by (roughly) 2 until the allocation succeeds, and continue allocating until either we've allocated enough space, or the allocation size drops below PAGE_SIZE, or we exceed dmat->maxsegs. --Some other things we'd need: --bus_dmamap_load_sglist()--I think jhb already did this as part of the sglist work, at least for amd64 --Structures in the busdma map to track allocated buffers so we could free them later. --Are there lower-level calls we could make to just allocate the physical pages instead of malloc()/contigmalloc()? The kva mapping for each allocated buffer segment isn't necessary. A lot of drivers would probably just want to mmap the sglist to userspace anyway. --Could we instead just integrate this multi-seg functionality into the default bus_dmamem_alloc()? We'd at least have to be able map the physical segments into a contiguous kva area--we wouldn't necessarily have to use an sglist in this case either. Let me know if this idea has any potential--if it does, I'd love to try implementing it:) --Jason ___ 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) with MAP_ANON honouring offset although it shouldn't
On Wed, Oct 21, 2009 at 10:51 AM, Alexander Best <
alexbes...@math.uni-muenster.de> wrote:
> although the mmap(2) manual states in section MAP_ANON:
>
> "The offset argument is ignored."
>
> this doesn't seem to be true. running
>
> printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1,
> 0x12345678));
>
> and
>
> printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1, 0));
>
> produces different outputs. i've attached a patch to solve the problem. the
> patch is similar to the one proposed in this PR, but should apply cleanly
> to
> CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258
>
The standards for mmap(2) actually disallow values of "off" that are not a
multiple of the page size.
See http://www.opengroup.org/onlinepubs/95399/functions/mmap.html for
the following:
[EINVAL]The *addr* argument (if MAP_FIXED was specified) or *off* is not a
multiple of the page size as returned by
*sysconf*(),
or is considered invalid by the implementation.Both Solaris and Linux
enforce this restriction.
I'm not convinced that the ability to specify a value for "off" that is not
a multiple of the page size is a useful differentiating feature of FreeBSD
versus Solaris or Linux. Does anyone have a compelling argument (or use
case) to motivate us being different in this respect?
If you disallow values for "off" that are not a multiple of the page size,
then you are effectively ignoring "off" for MAP_ANON.
Regards,
Alan
___
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 Wednesday 21 October 2009 11:30:51 am Alexander Best wrote: > Robert Watson schrieb am 2009-10-21: > > > On Wed, 21 Oct 2009, Alexander Best wrote: > > > >this code serves only one purpose: to trigger a segfault. i don't > > >use the code for any other purpose. i was under the impression that > > >mmap() should either succeed or fail (tertium non datur). mmap's > > >manual doesn't say anything about mmap() causing segfaults. > > > Have you tried ktracing the application? I think you'll find that > > mmap(2) system call succeeded fine, and that the segfault comes from > > attempting to execute the address in libc on return to userspace, as > > a result of libc not being at that address anymore (since you > > removed its mapping). You can use procstat -v to inspect address > > space use by processes, but as a general rule you don't want to pass > > anything other than an address of 0x0 to mmap(2) unless you're very > > carefully managing the address space of the process. Many userspace > > libraries are involved in using that address space, but especially > > the runtime linker which begins execution in userspace when a binary > > is started. > > > Robert N M Watson > > Computer Laboratory > > University of Cambridge > > > you're right. this kdump shows that the segfault isn't being caused by the > mmap() call: > > 88343 mmap_test CALL > mmap(0x1000,0x80047000,PROT_NONE,MAP_FIXED|MAP_ANON,0x,0,0) > 88343 mmap_test RET mmap 4096/0x1000 > 88343 mmap_test PSIG SIGSEGV SIG_DFL > 88343 mmap_test NAMI "mmap_test.core" > > thanks for clearing things up. > > however i stil think mentioning this situation in the mmap(2) manual (maybe in > section MAP_FIXED) would be a good idea. I'm not sure it is useful to attempt to enumerate all the possible ways one can shoot one's own foot using mmap(2) in the manual page. The list would be quite long and would require a large amount of imagination. In effect, you are asking for a manual page to document all the possible bugs one could have and manual pages in general do not do that. -- John Baldwin ___ 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) with MAP_ANON honouring offset although it shouldn't
On Wednesday 21 October 2009 11:51:04 am Alexander Best wrote:
> although the mmap(2) manual states in section MAP_ANON:
>
> "The offset argument is ignored."
>
> this doesn't seem to be true. running
>
> printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1,
> 0x12345678));
>
> and
>
> printf("%p\n", mmap((void*)0x1000, 0x1000, PROT_NONE, MAP_ANON, -1, 0));
>
> produces different outputs. i've attached a patch to solve the problem. the
> patch is similar to the one proposed in this PR, but should apply cleanly to
> CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71258
A simpler patch would be to simply set pos = 0 below the MAP_STACK line if
MAP_ANON is set.
--
John Baldwin
___
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"
