other when there was a pipe or udp connection between them. This
meant that a marked-as-interactive xterm would, when blocked waiting
for an Xserver response, transfer some of its interactiveness to the
Xserver, and aparently it worked very good for desktop workloads so,
maybe adapting it for th
blocked waiting
for an Xserver response, transfer some of its interactiveness to the
Xserver, and aparently it worked very good for desktop workloads so,
maybe adapting it for this new scheduler would be good.
--
Greetz, Antonio Vargas aka winden of network
http://network.amigascne.org/
[EMAIL
On 9/1/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Iau, 2005-09-01 at 08:00 +0200, Antonio Vargas wrote:
> > 2. whole screen z-buffer, for depth comparison between the pixels
> > generated from each window.
>
> That one I question in part - if the rectangles are
Jb3BMWBwVTA3sk=
> =k086
> -END PGP SIGNATURE-
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ a
://www.tux.org/lkml/
--
Greetz, Antonio Vargas aka winden of network
http://wind.codepixel.com/
Las cosas no son lo que parecen, excepto cuando parecen lo que si son.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On 9/1/05, Alan Cox [EMAIL PROTECTED] wrote:
On Iau, 2005-09-01 at 08:00 +0200, Antonio Vargas wrote:
2. whole screen z-buffer, for depth comparison between the pixels
generated from each window.
That one I question in part - if the rectangles are (as is typically the
case) large
h, have you had a look at the mac-on-linux virtualizer? It's coded
for arch-ppc but most probably some of these generic concepts could
get merged together...
--
Greetz, Antonio Vargas aka winden of network
http://wind.codepixel.com/
Las cosas no son lo que parecen, excepto cuando parecen lo
virtualizer? It's coded
for arch-ppc but most probably some of these generic concepts could
get merged together...
--
Greetz, Antonio Vargas aka winden of network
http://wind.codepixel.com/
Las cosas no son lo que parecen, excepto cuando parecen lo que si son.
-
To unsubscribe from this list: send
uch memory on i386.
>
>
> Erik
>
On 32bit: you would have to use read() and write() or mmap() munmap()
mremap() to perform your own paging, since you can't fit 15GB on a 4GB
address space.
On 64bit: you would simply mmap() the whole file and you are done.
Most probably
; --
> +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
> | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
> -
Bastian, Erik is dead-on on that one: go 64bit and forget all worries
about your 15GB filesize. Just don't forget to look not only x86-64
(intel
-
Bastian, Erik is dead-on on that one: go 64bit and forget all worries
about your 15GB filesize. Just don't forget to look not only x86-64
(intel or amd) but also itanium, ppc64 and s390 machines, you never
know about surprises!
--
Greetz, Antonio Vargas aka winden of network
http
and you are done.
Most probably the cost of programming and debugging the hand-made
paging on 32bit machines will cost more than the difference for a
64bit machine.
--
Greetz, Antonio Vargas aka winden of network
http://wind.codepixel.com/
Las cosas no son lo que parecen, excepto cuando parecen lo
le__ ("dcbtst 0,%0" : : "r" (x));
> }
>
> It seems that doing a prefetch on a NULL pointer, while it doesn't
> cause a fault, does waste time looking for a translation of the zero
> address.
>
> Paul.
Don't know exactly about power5, but G5 processor is des
looking for a translation of the zero
address.
Paul.
Don't know exactly about power5, but G5 processor is described on IBM
docs as doing automatic whole-page prefetch read-ahead when detecting
linear accesses.
--
Greetz, Antonio Vargas aka winden of network
http://wind.codepixel.com/
Las
14 matches
Mail list logo
