On Mon, May 01, 2000 at 02:19:24PM -0400, Alexander Viro wrote:
> >
> >
> > Ooops! I mean, aggregation, of course, but nevertheless I just try to
> > express the idea using less possible number of words.
> > Ok, what about the idea ?
>
> Tokens. Opaque tokens. Interface should not care about them. Callers must
> know what they are dealing with, indeed.
Al, the only thing I worry about is stable interface. I do not care about
"struct file *" or something like that just because I hope that with reasonable
and stable interface I can do what I want ( efficiency? well, I can sacrifice
it ;) ). So please, keep it coherent and stable. I mean, if you start adding
"struct file *" add it to the readpage in pre7. Ok ?
> > > > > Inode data pages are per-inode, not per-dentry or per-file-struct.
> > > >
> > > > Frankly, inode data pages are file pages, because it is userspace files we
> > > > care of. Nothing more, nothing less.
> > >
> > > You've missed the point here. We cache the data on the client
> > > side. _All_ openers share that cache.
> >
> > You mean local, client side openers ?
>
> Yep.
>
> > > IOW, we have a chance that data submitted by one of them will be sent with
> > > credentials of another. Nothing to do here.
> >
> > For now? Yes. But if we would be able to use "struct file *" than we could
> > store all meta information on a per opener basis. That's the idea. And we
> > could always separate one opener from another by syncing each and every
> > operation. Yes?
>
> All meta information? Consider mmap(). You have a dirty page.
Ok. Let's see how can we get this page:
1. client generate write(2) and generic_file_write writes to
the memory region. In this case we ought to generate Rwrite
immediately. Yes ?
2. client writes to the memory region ( in case of previous mmap )
*correct me if I am wrong* but I guess that it is up to the vm
subsystem to request sync, isn't it ? If yes, than we need not
generate Rwrite, just after the page turns to be dirty. Yes ?
> It might be dirtied by a process that has it mapped. It might be dirtied by
> direct write() by another opener. You end up with the need to generate Rwrite.
> And no way to separate the data from different openers. So either you use
> a new cache for each opener (_big_ waste of memory + hell of coherency
> problems) or you end up with the described effect.
I do understand what you mean ( we can not tell what opener wrote to the
page ) but I can not figure out what harm this effect could to to the
system [performance]. Tell me, please.
Thanks,
Roman.
