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/