linux-kernel - Re: [fuse-devel] [PATCHSET] FUSE: extend FUSE to support more operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 Nov 2008 10:33:47 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	tj@...nel.org
CC:	miklos@...redi.hu, fuse-devel@...ts.sourceforge.net,
	greg@...ah.com, linux-kernel@...r.kernel.org
Subject: Re: [fuse-devel] [PATCHSET] FUSE: extend FUSE to support more	operations

On Tue, 18 Nov 2008, Tejun Heo wrote:
> Miklos Szeredi wrote:
> > OK, lets do it with the original interface.  There's still room for
> > optimization, though, because the _normal_ operation of poll() is
> > absolutely asynchronous.
> 
> Hmm... I'm not sure I understand what you're saying but if you're
> talking about optimizing async case where notification occurs while the
> poller is sleeping, I don't think it really matters.  That could be
> common but they're not performance sensitive path.  As select/poll users
> become busy, ->poll operation becomes more and more synchronous.

If poll does have to sleep (however short), then it's alwasy more
synchronous than necessary.  It introduces an extra latency of two
context switches per poll.  Yes, this means the performance hit will
decrease as the sleep lengthens, but short sleep != no sleep.

> If the client is using better interface like epoll, sending revents via
> notification could help a bit but again the problem is that the ->poll
> vfs interface is not ready for that.  e.g. How do you tell whether
> ->poll is for epoll polling after the notification or an asynchronous
> poll(2) being called after a read(2) after the notification arrived.
> There simply isn't enough information to determine when the cached
> revents (no matter how short the period of caching is) can be used or
> not.  One thing we can do is to invalidate the received revents value on
> every file operation and then reverting to synchronous call only when
> cached revents is not available, but I don't really see good
> justifications for such over complexity.

It's an optimization, and not a very complex one at that.  But yes, we
should leave that till later, when the simple interface prooved itself
working.

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/