vm_map_findspace space search?
Hi, In svn r133636, there was a commit to convert the linear search in vm_map_findspace() to use the vm_map splay tree. Just curious, were there any discussions about that particular change? Any measurements other than the ones noted in the commit log? Any notes on why that design was used rather than any other? I've seen the 'Some mmap observations...' thread from about a year earlier and was wondering about some of the possible designs discussed there. In particular the Bonwick/Adams vmem allocator was brought up; I think that something inspired by it (and strangely close to the QuickFit malloc) would be appropriate: Here's how I see it working: * Add a series of power-of-two or logarithmic sized freelists to the vm_map structure; they would point to vm_map_entries immediately to the left of free space holes of a given size. * finding free space would just pop an entry off of the free space list and split in the usual way; deletion could coalesce in constant time. * Unlike the vmem allocator, we would not need to allocate external boundary tags; the vm_map_entries themselves would be the tags. At least from looking at the pattern of vm_map_findspace()s on DFly, the most common requests were for 1 page, 4 page, and 16 page-sized holes (iirc these combined for 75% of requests there; I imagine the pattern in FreeBSD would be very similar). The fragmentation concerns from this would be pretty minor with that pattern... Seem okay? Thoughts? Thanks! -- vs ___ 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: Driver memory allocation
On 12/15/10 4:33 AM, Dr. Baud wrote: Is there a cap on the amount of memory a driver (via bus_dmamem_alloc) can allocate, other than the obvious physical memory limit minus the memory already allocated? well it has to fit into the kernel virtual space too. this is quite limited on x86 though for amd64 it is a lot bigger. I have seen drivers on amd64 setting asside a couple of GB (but you need a new kernel that has the kernel virtual space expanded). The kernel can make use of the direct-map space for driver allocation too. Dr. ___ 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-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: IPSEC allegations
On Wed, Dec 15, 2010 at 06:56:58AM -0800, Jakub Lach wrote: > > Hello. > > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 > > What's your insight? > Someone has figured out how to get free code audit. Lots of paranoid people started to look at the code. Ingvar ___ 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: IPSEC allegations
On Wed, Dec 15, 2010 at 06:56:58AM -0800, Jakub Lach wrote: > > Hello. > > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 > > What's your insight? > Someone has figured out how to get free code audit. Lots of paranoid people started to look at the code. Ingvar ___ 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: IPSEC allegations
On Wed, 15 Dec 2010 06:56:58 -0800 (PST) Jakub Lach wrote: > > Hello. > > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 > > What's your insight? There's already a thread on this on the security list. ___ 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: IPSEC allegations
[redirected from -hackers to -security] Jakub Lach writes: > http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html 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"
Driver memory allocation
Is there a cap on the amount of memory a driver (via bus_dmamem_alloc) can allocate, other than the obvious physical memory limit minus the memory already allocated? Dr. ___ 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: LED support for ALIX 2/3 series
John Nielsen wrote: > On Dec 15, 2010, at 7:12 AM, Michael Reifenberger wrote: > > > On Wed, 15 Dec 2010, Emanuel Haupt wrote: > > > >> Date: Wed, 15 Dec 2010 12:38:23 +0100 > >> From: Emanuel Haupt > >> To: freebsd-hackers@FreeBSD.org > >> Subject: LED support for ALIX 2/3 series > >> Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 > >> series [2]? The following version uses linux API's. > >> > >> I'd gladly write a port for it if someone could port it. > >> > > > > Probably it should use the led(4) framework and reside in the base > > OS. Like sys/arm/xscale/ixp425/cambria_led.c > > The LED's on my Alix 3d2 work just fine already with led(4) under > 8.2. I think the code gets pulled in by "options CPU_GEODE". I have > three device nodes under /dev/led/ that work as described in the led > (4) manpage. Am I missing something? No, in this case I guess I was the one missing something :-) Thanks for pointing it out. Emanuel ___ 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: LED support for ALIX 2/3 series
On Dec 15, 2010, at 7:12 AM, Michael Reifenberger wrote: > On Wed, 15 Dec 2010, Emanuel Haupt wrote: > >> Date: Wed, 15 Dec 2010 12:38:23 +0100 >> From: Emanuel Haupt >> To: freebsd-hackers@FreeBSD.org >> Subject: LED support for ALIX 2/3 series >> Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 series [2]? >> The following version uses linux API's. >> >> I'd gladly write a port for it if someone could port it. >> > > Probably it should use the led(4) framework and reside in the base OS. > Like sys/arm/xscale/ixp425/cambria_led.c The LED's on my Alix 3d2 work just fine already with led(4) under 8.2. I think the code gets pulled in by "options CPU_GEODE". I have three device nodes under /dev/led/ that work as described in the led(4) manpage. Am I missing something? JN ___ 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"
IPSEC allegations
Hello. http://marc.info/?l=openbsd-tech&m=129236621626462&w=2 What's your insight? regards, - Jakub Lach -- View this message in context: http://old.nabble.com/IPSEC-allegations-tp30464535p30464535.html Sent from the freebsd-hackers mailing list archive at Nabble.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: LED support for ALIX 2/3 series
On Wed, 15 Dec 2010, Emanuel Haupt wrote: Date: Wed, 15 Dec 2010 12:38:23 +0100 From: Emanuel Haupt To: freebsd-hackers@FreeBSD.org Subject: LED support for ALIX 2/3 series Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 series [2]? The following version uses linux API's. I'd gladly write a port for it if someone could port it. Probably it should use the led(4) framework and reside in the base OS. Like sys/arm/xscale/ixp425/cambria_led.c Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.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: LED support for ALIX 2/3 series
On Wednesday 15 December 2010 12:38:23 Emanuel Haupt wrote: > Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 series > [2]? The following version uses linux API's. > > I'd gladly write a port for it if someone could port it. > > Emanuel > > [1] http://people.freebsd.org/~ehaupt/misc/leds-alix-0.0.1/leds-alix.c > [2] http://www.pcengines.ch/ > Hi, we have in CURRENT gpio framework with gpioctl control program and gpioled device. I think we should use this approach instead. In past I tested something similar on WRAP (older product, ALIX could be considered ancestor of it) and it works. Also, if you look at sys/i386/geode.c, there is already something written, which should be working... Regards, Milan ___ 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"
LED support for ALIX 2/3 series
Is anyone interested in porting leds-alix.c [1] for the ALIX 2/3 series [2]? The following version uses linux API's. I'd gladly write a port for it if someone could port it. Emanuel [1] http://people.freebsd.org/~ehaupt/misc/leds-alix-0.0.1/leds-alix.c [2] http://www.pcengines.ch/ ___ 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"
