On Mon Mar 28 2016 11:27, Otto Moerbeek wrote:
> Second diff. Only one person (Stefan Kempf, thanks!) gave feedback...
Sorry, running with this patch since a week, but missed to give
feedback.
As others already reported, no regressions here on amd64 also.
Hi Martin,
On Sat Mar 19 2016 13:53, Martin Pieuchot wrote:
> I'm also interested in hearing from more people using multi-threaded
> applications.
your patch - just like Michal's - improves the situation a lot.
Watching videos (HD) fullscreen in a browser without stuttering - the
GUI stays
Hi Michal,
On Fri Mar 18 2016 10:03, Edd Barrett wrote:
> On Thu, Mar 17, 2016 at 09:26:08PM +0100, Henrik Friedrichsen wrote:
> > On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote:
> > > Chrome still isn't smooth.
> > >
> > > Please test, and let me know if the performance of
Hi Otto,
On Wed Mar 9 2016 10:06, Otto Moerbeek wrote:
> Lightly tested by myself on amd64, you can help by reviewing and
> testing this.
I also don't see regressions on my amd64 - running since 3 days on my
production system.
Hi,
I can't comment on the code itself, but there's
> The
> taskq
> API provides a mechanism to defer work to a process context.
> .Pp
> +The
> +taskctx
> +API provides a mechanism to serialise work in a single context.
> +A taskctx guarantees that all work submitted to it will not run
>
On Wed Nov 25 2015 22:00, Gregor Best wrote:
> on amd64 with a snapshot from today, I'm getting (transcribed):
>
> kernel: page fault trap, code=0
> ddb{1}> trace
> vm_writepage() at vm_writepage+0x158
> VOP_IOCTL() at VOP_IOCTL+0x44
> vn_ioctl() at vn_ioctl+0x77
>
On Thu Nov 26 2015 15:11, Karel Gardas wrote:
> Not sure, but on misc you can search for "vmm uvm_fault in vmware
> player/workstation when Intel VT/AMD-v not enabled" thread from which
> it looks like vmm requires extended-page tables virtualization
> feature.
Looks like this could indeed be
On Sat Oct 24 2015 23:48, Mark Kettenis wrote:
> This diff needs to be tested on a wide range of hardware. So if you
> have a machine with inteldrm(4), please give it a shot. I'm
> particularly interested in testing on an x40.
No problems on my Thinkpad T400 (also running X11).
OpenBSD
Hello Martin,
On Tue Aug 25 2015 12:27, Martin Pieuchot wrote:
On 12/08/15(Wed) 17:03, Martin Pieuchot wrote:
I'm currently working on the routing table interface to make is safe
to use by multiple CPUs at the same time. The diff below is a big
step in this direction and I'd really
On Thu Jun 11 2015 09:20, Alexandre Ratchov wrote:
To test this diff, simply run your regular audio stuff and let us
know if you notice any difference. I'd suggest to keep a copy of
the old kernel in order to be able to compare easily.
I've been watching videos and listening to music with both
On Thu May 28 2015 11:28, Martin Pieuchot wrote:
Replace the last ether_input_mbuf() by if_input().
Successfully tested with OpenVPN.
On Tue Jul 30 2013 00:06, Mark Kettenis wrote:
Things to test are suspend/resume, whether the battery status is
properly reported and updated, whether the acpitz(4) temperature
sensors are still working, etc., etc. So please run with it for a bit
and report any breakage.
Lenovo T400. Tested
On Fri Oct 5 2012 14:24, Antoine Jacoutot wrote:
On Thu, Oct 04, 2012 at 11:42:45PM +0200, Gregor Best wrote:
As before, I'm looking forward to anything you have to comment, especially
cool
benchmark ideas or the like.
I know my report is not a benchmark of any kind but I do see a
On Wed Sep 19 2012 00:22, Paul Irofti wrote:
Any reason we have this disabled?
I ran with this diff in for quite some time w/o any problems.
Can you test this and let me know if anything bad happens?
My Thinkpad runs stable so far, everything still seems to work fine
(suspending to RAM also).
On Sat Sep 15 2012 20:44, Norman Golisz wrote:
On Wed Sep 12 2012 10:23, Matthew Dempsky wrote:
The diff below changes GCC's default behavior to -fstack-protector-all
(i.e., add stack protection code to every function instead of just
some based on heuristics), but you can still revert
On Sat Sep 22 2012 00:03, Norman Golisz wrote:
On Sat Sep 15 2012 20:44, Norman Golisz wrote:
On Wed Sep 12 2012 10:23, Matthew Dempsky wrote:
The diff below changes GCC's default behavior to -fstack-protector-all
(i.e., add stack protection code to every function instead of just
some
On Wed Sep 12 2012 10:23, Matthew Dempsky wrote:
The diff below changes GCC's default behavior to -fstack-protector-all
(i.e., add stack protection code to every function instead of just
some based on heuristics), but you can still revert to the heuristic
behavior by passing -fstack-protector
17 matches
Mail list logo
