On 20/02/19 10:27, Miklos Szeredi wrote: > On Tue, Feb 19, 2019 at 12:51 PM Boaz harrosh <boaz@xxxxxxxxxxxxx> wrote: >> > >> +4. An FS operation like create or WRITE/READ and so on arrives from application >> + via VFS. Eventually an Operation is dispatched to zus: >> + ▪ A special per-operation descriptor is filled up with all parameters. >> + ▪ A current CPU channel is grabbed. the operation descriptor is put on >> + that channel (ZT). Including get_user_pages or Kernel-pages associated >> + with this OPT. >> + ▪ The ZT is awaken, app thread put to sleep. >> + ▪ In ZT context pages are mapped to that ZT-vma. This is so we are sure >> + the map is only on a single core. And no other core's TLB is affected. >> + (This here is the all performance secret) > > I still don't get it. You say mapping the page to server address > space is the performance secret. I say it's a security issue as well > as being perfectly useless, except for special cases. > Already working on this. Will submit new code in a month. There is already an API of GET_BLOCK that returns one or more server blocks (vi dpp_t) to Kernel. Today it is used in mmap, to directly map pmem to application space. We will use this API to memcpy(nt) in kernel space. The mapping facility will be optional for zusFS(s) but the preferred way will be Kernel side copy. This is because vm_zap_ptes() is way way to slow in current design and I need things faster ... <> > Thanks, > Miklos > Thanks Boaz
