Dave Voutila writes:
> Dave Voutila writes:
>
>> vmd(8) users of tech@,
>>
>> NOTE: I have no intention to try to commit this prior to 6.9's release
>> due to its complexity, but I didn't want to "wait" to solicit testers or
>> potential feedback.
>
> Freeze is over, so bumping this thread with
On 24/04/21(Sat) 12:49, Mark Kettenis wrote:
> > Date: Sat, 24 Apr 2021 12:23:17 +0200
> > From: Martin Pieuchot
> >
> > On 20/03/21(Sat) 13:25, Martin Pieuchot wrote:
> > > Diff below refactors routines to stop/unstop processes and save the signal
> > > number which will/can be transmitted it
forwarding here so that attachments are not removed
-- Forwarded message -
From: Alessandro Pistocchi
Date: Sat, Apr 24, 2021 at 3:50 AM
Subject: Re: Fwd: umm_map returns unaligned address?
To: Theo de Raadt , Philip Guenther ,
OpenBSD misc
Hi,
apologies again.
I am not
Is it feasible to introduce a min and max frequency exposed to userspace?
Understand the reason behind using hw.perf percentages.
As an application developer, I'd find this very useful.
Just a thought.
Thanks.
Christian Weisgerber:
> > Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> > both amd64 and sparc64. That means the kernel lock will only be taken
> > for lower faults and some amap/anon code will now run without it.
>
> I ran an amd64 bulk build with this diff on top
On 2021/04/22 15:38, Martin Pieuchot wrote:
> Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> both amd64 and sparc64. That means the kernel lock will only be taken
> for lower faults and some amap/anon code will now run without it.
>
> I'd be interested to have this
On 24/04/21(Sat) 12:25, Mark Kettenis wrote:
> > Date: Sat, 24 Apr 2021 12:02:22 +0200
> > From: Martin Pieuchot
> >
> > Diff below merge the two allocators into one and remove unused
> > alignment/boundary arguments. This is a small cleanup that helps
> > me keep track of the remaining
> Date: Sat, 24 Apr 2021 12:23:17 +0200
> From: Martin Pieuchot
>
> On 20/03/21(Sat) 13:25, Martin Pieuchot wrote:
> > Diff below refactors routines to stop/unstop processes and save the signal
> > number which will/can be transmitted it in wait4(2). It does the following:
> >
> > - Move the
> Date: Sat, 24 Apr 2021 12:02:22 +0200
> From: Martin Pieuchot
>
> Diff below merge the two allocators into one and remove unused
> alignment/boundary arguments. This is a small cleanup that helps
> me keep track of the remaining allocators.
>
> ok?
Not sure. Is uvm_km_kmemalloc() going to
On 20/03/21(Sat) 13:25, Martin Pieuchot wrote:
> Diff below refactors routines to stop/unstop processes and save the signal
> number which will/can be transmitted it in wait4(2). It does the following:
>
> - Move the "hack" involving P_SINTR to avoid grabbing the SCHED_LOCK()
> recursively
Diff below merge the two allocators into one and remove unused
alignment/boundary arguments. This is a small cleanup that helps
me keep track of the remaining allocators.
ok?
Index: arch/arm/arm/pmap7.c
===
RCS file:
Hi,
Hrvoje Popovski has successfully tested this diff together with my
parallel network forwarding. A mbuf list is not MP safe and modifies
the next pointer within the mbuf.
Convert the ARP mbuf list to an mbuf queue that contins a mutex.
Update la_hold_total with atomic operations.
Note that
Hi,
* Stefan Sperling wrote:
> On Fri, Apr 23, 2021 at 12:28:42PM +0200, Matthias Schmidt wrote:
> > I had a new kernel with only your following patch running all day and
> > never encountered the situation as described in my last email.
> > Connection was stable and transfer rates remained
13 matches
Mail list logo
