- User Since
- Jun 4 2014, 10:38 AM (434 w, 3 d)
Wed, Sep 28
Mon, Sep 26
Thu, Sep 22
Wed, Sep 21
can this go in please?
Tue, Sep 20
I'm going to whack this altogether from tmpfs and ufs if there is no argument for keeping it within a week.
Looking at it now I think the feature needs to be whacked instead. I'll ship some diffs later.
Mon, Sep 19
Sun, Sep 18
Sat, Sep 17
- fix bugs
Fri, Sep 16
NO_KERNEL_PAUSE is definitely the better option here. there are other header abusers (most notably zfs) and a generic way to damage control this is needed.
Thu, Sep 15
Wed, Sep 14
@rmacklem can you give this patch a spin please concerning nfs parts? works for me(tm)
Tue, Sep 13
Mon, Sep 12
So I just ran pkg build. pkg-static spams sysctlbyname security.jail.jailed for example.
it can also shave the issetugid call, see https://reviews.freebsd.org/D23779
I don't know about vm.overcommit -- there were talks about replacing malloc and new one perhaps will not even look at this.
Sat, Sep 10
I'm guessing the original code was avoiding the call, expecting for it to happen in ufs_inactive later. This retains the ultimately racy nature, except avoids the interlock.
just get it in please so that i can close the ticket internally :) thanks
Fri, Sep 9
I looked around, OpenBSD has everything hardcoded, like so:
What's up with lock conversion to sx and exclusive-locking everywhere? If you really need to hold the lock the entire time, you can use rms locks instead. If read-locking for normal use can't be achieved, then I'm afraid this patch is a non-starter -- there is *tons* of parallel sysctl calls in fork+exec heavy workloads (most notably for malloc), so this would degrade performance.
Thu, Sep 8
I don't mind the names.
Wed, Sep 7
you mean a dedicated set for memptr users which also avoids branching on in/out? i'm on it :)
- add back consumer conversion
Send me a diff to whack the hwpmc stuff and I'll commit that bit. Commit message needs to start with "hwpmc: "
All the places I patched to use the new routines are used a lot and don't pass the flag in question, yet with the current code they pay for its existence -- once by checking for it to begin with, and later by checking for realloc.