Re: [PATCH, RFC] Don't do page stablization if !CONFIG_BLKDEV_INTEGRITY

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

 



On Wed, Mar 14, 2012 at 9:46 PM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote:
> On 03/14/2012 07:10 PM, Andy Lutomirski wrote:
>> On 03/08/2012 08:43 AM, Sage Weil wrote:
>> I'll add a simple workload.  I have a soft real-time program that has
>> two threads.  One of them fallocates some files, mmaps them, mlocks
>> them, and touches all the pages to prefault them.  (This thread has no
>> real-time constraints -- it just needs to keep up.)  The other thread
>> writes to the files.
>>
>> On Windows, this works very well.  On Linux without stable pages, it
>> almost works.  With stable pages, it's a complete disaster.  No amount
>> of minimizing the amount of time that pages under writeback can cause
>> writers to sleep will help -- writers *must not wait for io* when
>> writing mlocked, prefaulted pages for my code to work.
>>
>
> Right, this is Windows shit. If your goal is to never wait, IO
> as fast as possible, and use the least amount of CPU time
> then it's exactly the opposite of what you want to do.
> You want to do async Direct IO.

I don't care if the io is as fast as possible and I don't care about
cpu time (that's what multicore is for).  I care about real-time
threads not waiting.  And I'm not sure why the superior performance on
Windows is "shit".

In any case, there's no possible way that async direct I/O is as
low-latency as memcpy for short writes.

>
> Also as Dave Chinner said "Double/ring buffering with async
> IO dispatch"

That's certainly an option.  In fact, any program that has issues with
write latency due to stable pages or any other cause can do this.  But
it's more code, it's more likely to lose data on an application crash,
and it's annoying since the kernel *already* has a perfectly good page
cache and mmap mechanism that ought to work.

Also, double buffering is kind of a PITA when other threads might be
trying to real the same file at the same time.  That means I have to
get them all to find the same mapping, which can't live on an ext4
filesystem, requiring a daemon.

So I still claim my use case is valid, and I think Linux should handle
it better than it does now.  The proposed fix of getting rid of stable
pages when they're not needed is good enough for me.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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