Hi,
I have been trying to increase fork performance of openbsd/amd64 on KVM.
It turns out that when I increase the number of CPUs of a VM from 1 to 3,
a fork+exit micro benchmark is slowed down by a factor of 7.
The main reason for this seems to be a very large number of cross-CPU TLB
flushes
On 07/07/14(Mon) 13:46, Matthew Dempsky wrote:
p_sigmask is only modified by the owning thread from process context
(e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
but it can be accessed anywhere (e.g., interrupts or threads on other
CPUs). Currently sys_sigprocmask()
Date: Mon, 7 Jul 2014 13:46:03 -0700
From: Matthew Dempsky matt...@dempsky.org
p_sigmask is only modified by the owning thread from process context
(e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
but it can be accessed anywhere (e.g., interrupts or threads on other
I'll need this for some upcoming changes, at least to do it WITHOUT
adding the 3rd or 4th or 5th copy of the bpf_mtap loop. most of these
bpf_mtap_* are almost identical, minor differences in what to prepend,
and foremost: passing custom copy functions. since bpf_mtap is all
over the place I made
On Tue, Jul 8, 2014 at 1:21 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
There was a previous attempt to mark sigpromask(2) as nolock but if I
recall properly setting p_sigmask atomically is not enough and there's
still a possible race in ptsignal().
Have you looked into this function,
On Tue, Jul 8, 2014 at 1:29 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Mon, 7 Jul 2014 13:46:03 -0700
From: Matthew Dempsky matt...@dempsky.org
p_sigmask is only modified by the owning thread from process context
(e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
It's rare, but there *are* cases where a thread wants to sleep and
doesn't expect any wakeup() calls at all; e.g., nanosleep() and
sigsuspend(). In these cases, there's no point in requiring a valid
wait channel identifier or adding the thread to the sleep queue.
Diff below explicitly allows
Diff below converts the kernel to build with -std=gnu99. (For
simplicity, I've only included amd64 for now, but I'll make the same
change to all kernel Makefiles if this is ok.)
The only incompatibility (that I'm aware of) is that ISO C99's inline
semantics differ slightly from GNU C89's
On Thu, Jun 26, 2014 at 13:43, Arne Becker wrote:
Hi.
Now soliciting diffs to change readwrite to a loop with two buffers
that poll()s in all four directions. :)
Good thing you made me remember I wrote just this a while ago.
This is my first OpenBSD diff, so tell me if I missed anything
On Mon, Jun 30, 2014 at 21:26, Tobias Stoeckmann wrote:
Hi,
this diff merges NetBSD's revision 1.20 into our tree: There are
some memory leaks in resetDosDirSection.
This is not a simple merge, I have added some things:
- rootDir was not properly freed in NetBSD's commit
(actually
Date: Tue, 8 Jul 2014 11:17:35 -0700
From: Matthew Dempsky matt...@dempsky.org
Diff below converts the kernel to build with -std=gnu99. (For
simplicity, I've only included amd64 for now, but I'll make the same
change to all kernel Makefiles if this is ok.)
The only incompatibility (that
Date: Tue, 8 Jul 2014 09:05:38 -0700
From: Matthew Dempsky matt...@dempsky.org
On Tue, Jul 8, 2014 at 1:29 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Mon, 7 Jul 2014 13:46:03 -0700
From: Matthew Dempsky matt...@dempsky.org
p_sigmask is only modified by the owning thread
On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis mark.kette...@xs4all.nl wrote:
I disagree with this diff. We should discourage the use of GNU
extensions in our kernel. Therefore I think std=gnu99 would give the
wrong signal.
Can you clarify your concern? Currently we're (implicitly)
On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
I disagree with this diff. We should discourage the use of GNU
extensions in our kernel. Therefore I think std=gnu99 would give the
wrong signal.
Can you clarify your concern? Currently we're
On Tue, Jul 08, 2014 at 03:01:58PM -0400, Ted Unangst wrote:
I think it's safe to just have one goto label? free(NULL) is fine.
That's true. If we go into that direction, we can also use the cleanup
function that would be done at the end of directory processing.
Also put two variables static
On Tue, Jul 8, 2014 at 12:28 PM, Mark Kettenis mark.kette...@xs4all.nl wrote:
With that explanation, this sounds a lot more reasonable.
Ah, good. :) Sorry, I should have mentioned up front the followup
steps I had planned and the rationale for taking this path.
how would you like your deadbeef? well done?
since we support variable poison values, we should invert the patterns
sometimes to find bugs where the deadbeef values hide the bugs. (we
can of course do even more with extra tricksy bit patterns, but start
with this.)
Index: subr_poison.c
how would you like your deadbeef? well done?
since we support variable poison values, we should invert the patterns
sometimes to find bugs where the deadbeef values hide the bugs. (we
can of course do even more with extra tricksy bit patterns, but start
with this.)
I have been worried
Hi!
This diff adds a -U flag to dump that allows using disklabel
UIDs in /etc/dumpdates. That makes incremental dumps possible when a
disk is roaming between device files.
I'd be happy to receive comments.
Also, sorry for the noise in misc, and thanks to everyone pointing me
in the right
Updated diff below with the following changes:
- p_sigmask is now volatile, per kettenis's request
- kern_fork.c's memcpy() for p_startcopy needs to cast away the
volatile now
- kettenis pointed out atomic_swap_uint() isn't safe to use in MI code
yet, so for now proc_sigsetmask() just relies
This makes ifconfig scan indicate the type of encryption used on a network.
To make this work, the kernel must fill in RSN info every time it runs
a scan, not just if wpa was already enabled (i.e. the IEEE80211_F_RSNON
flag is already set).
While here, add missing definition for
Date: Tue, 8 Jul 2014 09:22:41 +0200 (CEST)
From: Stefan Fritsch s...@sfritsch.de
Hi,
I have been trying to increase fork performance of openbsd/amd64 on KVM.
It turns out that when I increase the number of CPUs of a VM from 1 to 3,
a fork+exit micro benchmark is slowed down by a
On Mon, Jul 7, 2014 at 1:46 PM, Matthew Dempsky matt...@dempsky.org wrote:
p_sigmask is only modified by the owning thread from process context
(e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
but it can be accessed anywhere (e.g., interrupts or threads on other
CPUs).
On Tue, Jul 8, 2014 at 3:51 PM, Philip Guenther guent...@gmail.com wrote:
* using atomics when we don't even have correct process-pending signals
risks a solution that
doesn't work when more than one pending set has to be examined.
I'll hold off on this until we have process-pending
Hi everyone --
port-modules.5 is missing an If to make a complete sentence.
OK?
~Brian
Index: port-modules.5
===
RCS file: /cvs/src/share/man/man5/port-modules.5,v
retrieving revision 1.172
diff -u -p -r1.172 port-modules.5
---
On Tue, Jul 8, 2014 at 9:59 PM, Brian Callahan bcal...@devio.us wrote:
Hi everyone --
port-modules.5 is missing an If to make a complete sentence.
OK?
ok daniel@
~Brian
Index: port-modules.5
===
RCS file:
On 5.4-RELEASE, I'm trying to use growfs to expand a root filesystem.
I've grown the disk from 2GB to 10GB, I've used disklabel(8) to adjust
the OpenBSD area and the size of partition 'a'. All those numbers line up.
Rebooting into bsd.rd, copying /sbin/growfs to the ramdisk, and then
using it
The current divert(4) implementation allocates an mbuf tag in pf_test()
to store the divert port specified by a divert-packet PF rule.
The divert_packet() function then looks up that mbuf tag to retrieve the
divert port number before sending the packet to userspace.
As far as I can tell, this
On Tue, Jul 08, 2014 at 09:41:08PM -0500, Adam Thompson wrote:
On 5.4-RELEASE, I'm trying to use growfs to expand a root filesystem. I've
grown the disk from 2GB to 10GB, I've used disklabel(8) to adjust the
OpenBSD area and the size of partition 'a'. All those numbers line up.
Rebooting
29 matches
Mail list logo
