Re: multi-pool malloc wip diff

> - Curently fixed at 4 pools with a fixed thread -> pool mapping. > - All pools are always initialized, even for single threaded programs, > where >   only one pool is used. > - Especially realloc gets quite a bit uglier. > - I'm pondering storing the thread -> pool mapping in the thread >  

vlan(4) doesnt have to filter its own mac address

because the network stack does it for it on the way in. the following chunk in src/sys/net/if_ethersubr.c does the same job later on: int ether_input(struct ifnet *ifp, struct mbuf *m, void *cookie) { ... /* * If packet is unicast, make sure it is for us. Drop otherwise.

manpages for bpf_mtap(9) and co

im sure these could be improved, but that can be done in tree right? ok? Index: Makefile === RCS file: /cvs/src/share/man/man9/Makefile,v retrieving revision 1.272 diff -u -p -r1.272 Makefile --- Makefile15 Mar 2016 04:19:26

make bpf_mtap return whether to drop the packet or not

the end goal is to be able to pass the mbuf as a const. at the moment we still mark the packet with M_FILDROP to keep the changes minimal, but that will change in a later diff. ok? Index: bpf.h === RCS file:

Re: tcp syn cache random reseed

On Mon, Mar 21, 2016 at 12:58:41PM +0100, Alexander Bluhm wrote: > The attack I see is that you can measure the bucket distribution > by timing the SYN+ACK response. You can collect samples that end > in the same bucket. After you have collected enough, start your > DoS attack. I think that

Re: tcp syn cache random reseed

On Mon, Mar 21, 2016 at 11:05:25AM +0100, Martin Pieuchot wrote: > I like it. Do you think it could be useful to export the value of the > current active cache set and/or the value of ``tcp_syn_use_limit''? When the active cache set switches, the reseed counter increments. It might be usefull to

Cleaner way to disable acpivout(4)

Simply don'tmatch if the ws_get_param or ws_set_param callback has been set. That way we don't need the platform-specific acpi driver "enabled" variables anymore. ok? Index: acpi.c === RCS file: /cvs/src/sys/dev/acpi/acpi.c,v

Re: let's get reference to state key back

Hello, > i can't see any problem with this patch. i'm sending 14Mpps ip4 and ip6 > over ix intefaces and creating around 3M to 5M states and all this more > than 24 hours. box is unusable but it's alive :) thank you very much for testing. let's wait day or two to give other folks chance to trip

Re: Scheduler hack for multi-threaded processes

Hey, On Mon, Mar 28, 2016 at 02:00:13PM +0200, Alexandre Ratchov wrote: > do you mean that sound stuttes if the diff is applied but doesn't > stutter without the diff? Stuttering may have been an exaggeration. It's more of a short, bassy click than a stutter, really. Could be that it already

dwiic attach

The diff below makes the dwiic(4) driver's match function behave like the other acpi attach functions by matching on the _HID. This way it will continue to atach with the diff I sent out earlier today. I deliberately did not use the #define's from acpireg.h here. I intend to remove those. Just

acpi device attachment

Adding each and every new acpi device driver to acpi_foundhid() is gettingabit of the burden. And it really isn't how our autoconf framework is supposed to work for busses that can be enumerated. All the drivers already check for a matching _HID in their attach function. So we can just drop the

Re: acpi gpio support

> Date: Mon, 28 Mar 2016 21:49:39 +1100 > From: Jonathan Gray > > On Sun, Mar 27, 2016 at 09:28:25PM +0200, Mark Kettenis wrote: > > The diff below is a first stab at adding support for GPIOs as defined > > in ACPI 5.0. The primary target for this new ACPI feature is hardware >

Re: acpi gpio support

> Date: Sun, 27 Mar 2016 20:29:29 -0700 > From: Philip Guenther > > On Sun, Mar 27, 2016 at 12:28 PM, Mark Kettenis > wrote: > > The diff below is a first stab at adding support for GPIOs as defined > > in ACPI 5.0. The primary target for this new

handle bogus sparc64 frame buffers

Some sparc64 pci frame buffers incorrectly have the `depth' property spelled `depth ' with a trailing space. This can be found in this E450 eeprom -p output: http://pastebin.com/P4ab4Xt4 Because of this, gfxp(4) attaches believing the display is only 8bpp, and the display gets garbled. The

lpd systrace policy update

Probably going to be obsolete once lpd gets pledged, but as it stands, the lpd systrace policy is missing these system calls. Index: usr_sbin_lpd === RCS file: /home/cvs/src/etc/systrace/usr_sbin_lpd,v retrieving revision 1.9 diff

Re: make vlan(4) remember its parent by index, not by reference

> On 23 Mar 2016, at 12:36 AM, Masao Uebayashi wrote: > > On Tue, Mar 22, 2016 at 09:36:18PM +1000, David Gwynne wrote: >> this basically makes the code use if_get instead of carrying a >> pointer around. this is as mechanical as i can make it. >> >> ok? >> >> Index:

Re: Scheduler hack for multi-threaded processes

On Mon, Mar 28, 2016 at 12:41:01PM +0200, Henrik Friedrichsen wrote: > Can confirm all the reports regarding desktop apps becoming more > responsive. I do, however, experience sound stutters, e.g. when playing > music in the browser (Google Play Music) or movies with mpv. do you mean that sound

Re: multi-pool malloc wip diff

Just a subjective opinion (if that counts as feedback): This in combination with the scheduler patch by mpi@ seems to greatly improve the browsing experience with Chrome, esp. when opening/closing tabs, which I suppose involves a lot of memory management calls? Other than that I haven't noticed

Re: acpi gpio support

On Sun, Mar 27, 2016 at 09:28:25PM +0200, Mark Kettenis wrote: > The diff below is a first stab at adding support for GPIOs as defined > in ACPI 5.0. The primary target for this new ACPI feature is hardware > reduced platforms like those based on Intel's Bay Trail SoC. The diff > adds a

Re: Scheduler hack for multi-threaded processes

Can confirm all the reports regarding desktop apps becoming more responsive. I do, however, experience sound stutters, e.g. when playing music in the browser (Google Play Music) or movies with mpv. Interestingly, this does not seem to happen when playing YouTube videos.

Re: multi-pool malloc wip diff

On Mon, Mar 28, 2016 at 11:43:22AM +0200, Otto Moerbeek wrote: > No specifics, just watch out for malloc related bugs. It's > both important that non-threaded programs and non-threaded programs > show no new bugs. And don't forget to test non-threaded programs ;-)

Re: multi-pool malloc wip diff

On Mon, Mar 28, 2016 at 03:40:21AM -0600, Abel Abraham Camarillo Ojeda wrote: > On Mon, Mar 28, 2016 at 3:27 AM, Otto Moerbeek wrote: > > On Wed, Mar 23, 2016 at 08:00:19AM +0100, Otto Moerbeek wrote: > > > >> Hi, > >> > >> first diff that seems to work. Tested on amd64 and

Re: multi-pool malloc wip diff

On Mon, Mar 28, 2016 at 3:27 AM, Otto Moerbeek wrote: > On Wed, Mar 23, 2016 at 08:00:19AM +0100, Otto Moerbeek wrote: > >> Hi, >> >> first diff that seems to work. Tested on amd64 and compile tested on >> sparc64. >> >> It is alo available at http://www.drijf.net/openbsd/malloc

Re: uvm: enable amap per-page refcounting unconditionally

Miod Vallat wrote: > > > It seems per-page reference counting is used since forever. I think > > there's no reason to ever turn it off (and track referenced pages > > with less accuracy, causing leaks). > > Actually, assuming the #undef code path works, it might work keeping > this and only

Re: multi-pool malloc wip diff

On Wed, Mar 23, 2016 at 08:00:19AM +0100, Otto Moerbeek wrote: > Hi, > > first diff that seems to work. Tested on amd64 and compile tested on > sparc64. > > It is alo available at http://www.drijf.net/openbsd/malloc > > Form the README: > > The diff should be applied while in /usr/src/lib,

Re: www.openbsd.org/cgi-bin/man.cgi

I was thinking more of having a Javascript implementation of OpenBSD so that you could type the 'man' command to get the page you are after. It will only increase the size of the page by about 400MB, and hard disk and CPU space is cheap. And everyone has infinite bandwidth internet. On Fri, 25

Re: wsdisplay_compat_usl/KDENABIO: no need to specisal case i386

Matthieu Herrb writes: > Hi, > > OpenBSD has stopped using the SVr4 KDENABIO/KDDISABIO ioctls for at > least 10 years. No need for special treatement on i386. > > ok? yup -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE