By: rwessel (robertwessel.delete@this.yahoo.com), January 31, 2017 1:29 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on January 30, 2017 10:01 am wrote:
> rwessel (robertwessel.delete@this.yahoo.com) on January 29, 2017 8:56 pm wrote:
> Yeah, I'm, aware of the high-level details, the oddities are in the low-level issues
> (very strange TLB flushing, iirc, due to some odd dirty bit handling and other rules,
> I only see the patches flow by, I've never used it or looked all that closely).
Well, given Linux's heritage, the dirty and referenced bits on S/360 are certainly odd (as they're attached to the physical page and not the TLB entry). Having some of the protection bits attached to the physical page probably also annoys the Linux kernel...
> > While fast TLB reloads are certainly a good thing, they are still an expense, avoiding unnecessary discards
> > of TLB entries, especially on short switches to different address spaces, compliments that.
>
> No disagreement. Although I personally find that to be more of a SW design issue: people
> who design their calling conventions to be about cross-process boundaries are crazy.
It has its moment, though. As an example, if you've done a DB2 SELECT, each of the subsequent FETCH's is just a wrapper around a PC (call-gate to DB2's address space). DB2, can then deposit the row right into your address space (there being pretty good cross address space support in zArch). Other solutions can reduce the number of cross address space calls (for example, buffering multiple rows), but at the expense of complexity and copies of the data.
> rwessel (robertwessel.delete@this.yahoo.com) on January 29, 2017 8:56 pm wrote:
> Yeah, I'm, aware of the high-level details, the oddities are in the low-level issues
> (very strange TLB flushing, iirc, due to some odd dirty bit handling and other rules,
> I only see the patches flow by, I've never used it or looked all that closely).
Well, given Linux's heritage, the dirty and referenced bits on S/360 are certainly odd (as they're attached to the physical page and not the TLB entry). Having some of the protection bits attached to the physical page probably also annoys the Linux kernel...
> > While fast TLB reloads are certainly a good thing, they are still an expense, avoiding unnecessary discards
> > of TLB entries, especially on short switches to different address spaces, compliments that.
>
> No disagreement. Although I personally find that to be more of a SW design issue: people
> who design their calling conventions to be about cross-process boundaries are crazy.
It has its moment, though. As an example, if you've done a DB2 SELECT, each of the subsequent FETCH's is just a wrapper around a PC (call-gate to DB2's address space). DB2, can then deposit the row right into your address space (there being pretty good cross address space support in zArch). Other solutions can reduce the number of cross address space calls (for example, buffering multiple rows), but at the expense of complexity and copies of the data.
