> > If you are concerned about performance, I recommend you upgrade to a
> > computer with a hardware accelerated xor instruction.
>
> By the only hardware accelarated operation my computer has is NAND...
Well, consider yourself lucky, mine only accelerates NOP.
On Wed, Apr 17, 2013 at 08:06:43PM -0400, Ted Unangst wrote:
> At some point, every young programmer hears a story about how you can
> use xor to store the pointers of a list. It's a stupid story for many
> reasons, not least of which is the fact that nobody ever does this.
> Sounds like a challen
At some point, every young programmer hears a story about how you can
use xor to store the pointers of a list. It's a stupid story for many
reasons, not least of which is the fact that nobody ever does this.
Sounds like a challenge.
This diff doesn't actually implement anything like what you're
pr
On Wed, Apr 17, 2013 at 1:47 AM, Alexandre Ratchov wrote:
> On Mon, Apr 08, 2013 at 12:09:15PM +0200, Alexandre Ratchov wrote:
>> This diff is to add audio-specific locking in order to stop taking
>> the global kernel lock in audio interrupt code paths. With this,
>> audio drivers don't have to wa
On Wed, Apr 17, 2013 at 15:39, Ted Unangst wrote:
> Some functions dealing with pegging procs to CPUs and migration costs
> are only meaningful if we are running a multiprocessor kernel. Leave
> dummy versions in to avoid ifdef mazes elsewhere.
Here's a variant that covers a bit more code, by stub
On Wed, Apr 17, 2013 at 13:41, Theo de Raadt wrote:
> Please #ifdef the bodies of the functions, rather than adding wrappers
> afterwards.
The problem is sched_proc_to_cpu_cost has a bunch of globals outside it,
so excluding them would add several more ifdef/endif sections. Doable,
I just didn't l
Please #ifdef the bodies of the functions, rather than adding wrappers
afterwards.
> Some functions dealing with pegging procs to CPUs and migration costs
> are only meaningful if we are running a multiprocessor kernel. Leave
> dummy versions in to avoid ifdef mazes elsewhere.
>
> Index: kern_sch
Some functions dealing with pegging procs to CPUs and migration costs
are only meaningful if we are running a multiprocessor kernel. Leave
dummy versions in to avoid ifdef mazes elsewhere.
Index: kern_sched.c
===
RCS file: /cvs/src/sy
On Mon, Apr 15, 2013 at 15:27, Pedro Martelletto wrote:
>>http://block.io/tmpfs/tmpfs4.diff
>
> My bad, the correct URL is:
>
> http://block.io/tmp/tmpfs4.diff
>
> -p.
One more note. We already have a fmt_scaled function in libutil which would
be better than introducing a private dehumanisze_nu
Now that all our USB controllers use the same wrapper around
usb_allocmem() and usb_freemem() for allocating buffers for
transfers and taking into consideration that they also use these
functions directly internally, can I get rid of this layer?
Index: ehci.c
==
On 16/04/13(Tue) 14:44, Martin Pieuchot wrote:
> Diff below merge two slightly different versions of our kernel's
> inet_ntoa(). I picked 8 rooms for ip4buf to be consistent with
> what ip6_sprintf() does.
Please disregard this diff, I think that keeping these static buffers
around is not the way
On Mon, Apr 08, 2013 at 12:09:15PM +0200, Alexandre Ratchov wrote:
> This diff is to add audio-specific locking in order to stop taking
> the global kernel lock in audio interrupt code paths. With this,
> audio drivers don't have to wait until other kernel calls complete
> (including heavy syscalls
12 matches
Mail list logo
