Re: [RFC] what to do with IOCB_DSYNC?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/22/22 1:04 PM, Al Viro wrote:
> On Sun, May 22, 2022 at 12:48:20PM -0600, Jens Axboe wrote:
>> On 5/22/22 12:39 PM, Al Viro wrote:
>>> On Sun, May 22, 2022 at 12:29:16PM -0600, Jens Axboe wrote:
>>>> It was sent out as a discussion point, it's not a submission and it's by
>>>> no means complete (as mentioned!). If you're working on this, I'd be
>>>> happy to drop it, it's not like I really enjoy the iov_iter code... And
>>>> it sounds like you are?
>>>
>>> *snort*
>>>
>>> Yes, I am working on it.  As for enjoying that thing...  I'm not fond of
>>
>> OK great, I'll abandon this sandbox. Let me know when you have something
>> to test, and I can compare some numbers between non-iter, iter,
>> iter-with-ubuf.
>>
>>> forests of macros, to put it mildly.  Even in the trimmed form it still
>>> stinks, and places like copy_page_to_iter for iovec are still fucking
>>> awful wrt misguided microoptimization attempts - mine, at that, so I've
>>> nobody else to curse ;-/
>>
>> And it's not even clear which ones won't work with the generic variants,
>> and which ones are just an optimization. I suspect a lot of the icache
>> bloat from this just makes things worse...
> 
> ???
> 
> copy_page_{from,to}_iter() iovec side is needed not for the sake of
> optimizations - if you look at the generic variant, you'll see that it's
> basically "kmap_local_page + copy_{to,from}_iter() for the contents +
> kunmap_local_page", which obviously relies upon the copy_{to,from}_iter()
> being non-blocking.  So iovec part of it genuinely needs to differ from
> the generic variant; it's just that on top of that it had been (badly)
> microoptimized.  So were iterators, but that got at least somewhat cleaned

Right, I'm saying it's not _immediately_ clear which cases are what when
reading the code.

> up a while ago.  And no, turning that into indirect calls ended up with
> arseloads of overhead, more's the pity...

It's a shame, since indirect calls make for nicer code, but it's always
been slower and these days even more so.

> Anyway, at the moment I have something that builds; hadn't tried to
> boot it yet.

Nice!

-- 
Jens Axboe




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux