> > Make an empty map for little-endian direct access and make a backing
> > map with the actual file. Then install a signal handler to catch
> > reads in the empty map, copy a page (or more) with byteswapping, and
> > you're done. "Loading" is still extremely fast.
>
> Yes, "loading" a subsection of the data is still (fairly) fast. But
> that doesn't solve the other problem: huge swap space consumption when
> you want to access the entire dataset. It's often the case that you
> have much more data disc than you have swap disc.
Does a method exist to mark the copied pages discardable so they don't end
up on swap? Obviously not a perfect solution, but not bad.
> > As David Miller suggests, this might be a complete non-issue. We can
> > for instance speculate that the processor has a byteswap micro-op
> > that can be added to an instruction pipeline with little or no
> > cost. Or other such magic. Remember, we're talking about a fairly
> > novel architecture.
>
> Special BE load instructions are going to be messy to use, because you
> have to keep track of "where" the data came from (mmap() or malloc())
> all the way along.
>
> The possibility of tagging regions for BE access via the page tables
> looks good, though. Hopefully IA-64 will support it. And hopefully
> Linus accepts such an approach.
An alternate hack might be to push the on-the-fly-swap I suggested down
into the VM layer by having a flag somewhere in the mmap API. This is
cute, because then whether the swap were being done by a bit in the page
tables or by software, it could be portable to other Linux platforms.
Yes, I know it's sick. And I haven't even told you the really disgusting
part: the DSM folks will love it because it lets them share memory between
architectures! Don't choke, Larry!
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/