Messages in this thread | | | Date | Tue, 9 Mar 1999 16:33:07 +1100 | From | Richard Gooch <> | Subject | Re: Linux/IA-64 byte order |
| |
Oliver Xymoron writes: > On Tue, 9 Mar 1999, Richard Gooch wrote: > > > > 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.
Not that I know of. BTW: I don't really see how your scheme would work, since I don't think you could "make an empty map" anyway. All you could do is find a vacant region in VM, and mmap() a single page at a time as you needed it. That's horrible.
> > > 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.
You don't need to hack the VM layer to do this. You could probably implement it in a device driver which provided a mmap()able device. But the problem is you'd need root privileges to load the module.
> 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!
You have an evil sense of humour.
Regards,
Richard....
- 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/
| |