[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120821.202945.2278895156403194101.davem@davemloft.net>
Date: Tue, 21 Aug 2012 20:29:45 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: hpa@...or.com
Cc: bhutchings@...arflare.com, tglx@...utronix.de, mingo@...hat.com,
netdev@...r.kernel.org, linux-net-drivers@...arflare.com,
x86@...nel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
From: "H. Peter Anvin" <hpa@...or.com>
Date: Tue, 21 Aug 2012 20:24:18 -0700
> I'm all ears... tell me how sparc64 deals with this, maybe we can
> implement something similar. At the same time, do keep in mind that on
> x86 this is not just a matter of the FPU state, but the entire "extended
> state" which can be very large.
Sparc's state is pretty huge too. 256 bytes worth of FPU registers,
plus a set of 64-bit control registers.
What we do is we have a FPU stack that grows up from the end of the
thread_info struct, towards the bottom of the kernel stack.
Slot 0 is always the user FPU state.
Slot 1 and further are kernel FPU state save areas.
We hold a counter which keep track of how far deeply saved we are
in the stack.
Not for the purpose of space saving, but for overhead reduction we
sometimes can get away with only saving away half of the FPU
registers. The chip provides a pair of dirty bits, one for the lower
half of the FPU register file and one for the upper half. We only
save the bits that are actually dirty.
Furthermore, when we have FPU using code in the kernel that only uses
the lower half of the registers, we only save away that part of the
state around the routine.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists