On Mon, Aug 19, 2013 at 4:23 PM, David Lang wrote:
> On Fri, 16 Aug 2013, Dave Chinner wrote:
>
>> The problem with "not exported, don't update" is that files can be
>> modified on server startup (e.g. after a crash) or in short
>> maintenance periods when the NFS service is down. When the server
On Fri, 16 Aug 2013, Dave Chinner wrote:
The problem with "not exported, don't update" is that files can be
modified on server startup (e.g. after a crash) or in short
maintenance periods when the NFS service is down. When the server is
started back up, the change number needs to indicate the fi
On Mon, Aug 19, 2013 at 3:17 PM, J. Bruce Fields wrote:
> On Thu, Aug 15, 2013 at 04:01:49PM +1000, Dave Chinner wrote:
>> On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy Lutomirski wrote:
>> > On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner wrote:
>> > > On Wed, Aug 14, 2013 at 09:11:01PM -0400, Th
On Thu, Aug 15, 2013 at 04:01:49PM +1000, Dave Chinner wrote:
> On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy Lutomirski wrote:
> > On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner wrote:
> > > On Wed, Aug 14, 2013 at 09:11:01PM -0400, Theodore Ts'o wrote:
> > >> On Wed, Aug 14, 2013 at 04:38:12PM -
On Fri, Aug 16, 2013 at 04:18:33PM -0700, Andy Lutomirski wrote:
> On Fri, Aug 16, 2013 at 3:02 PM, J. Bruce Fields wrote:
> > On Fri, Aug 16, 2013 at 07:37:25AM +1000, Dave Chinner wrote:
> >> On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote:
> >> > On Thu, Aug 15, 2013 at 12:11 AM
On Fri, Aug 16, 2013 at 3:02 PM, J. Bruce Fields wrote:
> On Fri, Aug 16, 2013 at 07:37:25AM +1000, Dave Chinner wrote:
>> On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote:
>> > On Thu, Aug 15, 2013 at 12:11 AM, Dave Chinner wrote:
>> > > On Wed, Aug 14, 2013 at 11:14:37PM -0700, A
On Fri, Aug 16, 2013 at 07:37:25AM +1000, Dave Chinner wrote:
> On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote:
> > On Thu, Aug 15, 2013 at 12:11 AM, Dave Chinner wrote:
> > > On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski wrote:
> > >> On Wed, Aug 14, 2013 at 11:01 PM,
On Thu, Aug 15, 2013 at 5:14 PM, Dave Chinner wrote:
> On Thu, Aug 15, 2013 at 03:26:09PM -0700, Andy Lutomirski wrote:
>> On Thu, Aug 15, 2013 at 3:18 PM, Dave Chinner wrote:
>> > On Thu, Aug 15, 2013 at 02:43:09PM -0700, Andy Lutomirski wrote:
>> >> On Thu, Aug 15, 2013 at 2:37 PM, Dave Chinner
On Thu, Aug 15, 2013 at 03:26:09PM -0700, Andy Lutomirski wrote:
> On Thu, Aug 15, 2013 at 3:18 PM, Dave Chinner wrote:
> > On Thu, Aug 15, 2013 at 02:43:09PM -0700, Andy Lutomirski wrote:
> >> On Thu, Aug 15, 2013 at 2:37 PM, Dave Chinner
> >> wrote:
> >> > On Thu, Aug 15, 2013 at 08:17:18AM -07
On Thu, Aug 15, 2013 at 3:18 PM, Dave Chinner wrote:
> On Thu, Aug 15, 2013 at 02:43:09PM -0700, Andy Lutomirski wrote:
>> On Thu, Aug 15, 2013 at 2:37 PM, Dave Chinner
>> wrote:
>> > On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote:
>> >> My behavior also means that, if an NFS
>>
On Thu, Aug 15, 2013 at 02:43:09PM -0700, Andy Lutomirski wrote:
> On Thu, Aug 15, 2013 at 2:37 PM, Dave Chinner
> wrote:
> > On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote:
> >> My behavior also means that, if an NFS
> >> client reads and caches the file between the two writes, t
On Thu, Aug 15, 2013 at 2:37 PM, Dave Chinner wrote:
> On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote:
>> I didn't think of that at all.
>>
>> If userspace does:
>>
>> ptr = mmap(...);
>> ptr[0] = 1;
>> sleep(1);
>> ptr[0] = 2;
>> sleep(1);
>> munmap();
>>
>> Then current kernels
On Thu, Aug 15, 2013 at 02:31:14PM -0700, Andy Lutomirski wrote:
> On Thu, Aug 15, 2013 at 2:28 PM, Dave Chinner wrote:
> > On Thu, Aug 15, 2013 at 09:45:31AM +0200, Jan Kara wrote:
> >> On Thu 15-08-13 17:11:42, Dave Chinner wrote:
> >> > On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski
On Thu, Aug 15, 2013 at 08:17:18AM -0700, Andy Lutomirski wrote:
> On Thu, Aug 15, 2013 at 12:11 AM, Dave Chinner wrote:
> > On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski wrote:
> >> On Wed, Aug 14, 2013 at 11:01 PM, Dave Chinner wrote:
> >> > On Wed, Aug 14, 2013 at 09:32:13PM -0700,
On Thu, Aug 15, 2013 at 2:28 PM, Dave Chinner wrote:
> On Thu, Aug 15, 2013 at 09:45:31AM +0200, Jan Kara wrote:
>> On Thu 15-08-13 17:11:42, Dave Chinner wrote:
>> > On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski wrote:
>> > > On Wed, Aug 14, 2013 at 11:01 PM, Dave Chinner
>> > > wro
On Thu, Aug 15, 2013 at 09:45:31AM +0200, Jan Kara wrote:
> On Thu 15-08-13 17:11:42, Dave Chinner wrote:
> > On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski wrote:
> > > On Wed, Aug 14, 2013 at 11:01 PM, Dave Chinner
> > > wrote:
> > > > On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy L
On Thu, Aug 15, 2013 at 10:45:09AM -0700, Dave Hansen wrote:
>
> I _believe_ this is because the block allocation is occurring during the
> warmup, even in those numbers I posted previously. will-it-scale forks
> things off early and the tests spend most of their time in those while
> loops. Eac
On 08/15/2013 08:05 AM, Theodore Ts'o wrote:
> IOW, if it really is about write page fault handling, the simplest
> test to do is to mmap /dev/zero and then start dirtying pages. At
> that point we will be measuring the VM level write page fault code.
As I mentioned in some of the other replies,
On 08/14/2013 09:29 PM, Dave Chinner wrote:
> On Wed, Aug 14, 2013 at 07:24:01PM -0700, Andi Kleen wrote:
>>> And FWIW, it's no secret that XFS has more per-operation overhead
>>> than ext4 through the write path when it comes to allocation, so
>>> it's no surprise that on a workload that is highly
On Thu, Aug 15, 2013 at 12:11 AM, Dave Chinner wrote:
> On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski wrote:
>> On Wed, Aug 14, 2013 at 11:01 PM, Dave Chinner wrote:
>> > On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy Lutomirski wrote:
>> >> On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinn
On 08/14/2013 06:11 PM, Theodore Ts'o wrote:
> The point is that if the goal is to measure page fault scalability, we
> shouldn't have this other stuff happening as the same time as the page
> fault workload.
will-it-scale does several different tests probing at different parts of
the fault path:
On 08/14/2013 05:24 PM, Dave Chinner wrote:
> On Wed, Aug 14, 2013 at 10:10:07AM -0700, Dave Hansen wrote:
>> We talked a little about this issue in this thread:
>>
>> http://marc.info/?l=linux-mm&m=137573185419275&w=2
>>
>> but I figured I'd follow up with a full comparison. ext4 is about 20
On Wed, Aug 14, 2013 at 10:10:07AM -0700, Dave Hansen wrote:
> We talked a little about this issue in this thread:
>
> http://marc.info/?l=linux-mm&m=137573185419275&w=2
>
> but I figured I'd follow up with a full comparison. ext4 is about 20%
> slower in handling write page faults than ex
On Thu 15-08-13 17:11:42, Dave Chinner wrote:
> On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski wrote:
> > On Wed, Aug 14, 2013 at 11:01 PM, Dave Chinner wrote:
> > > On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy Lutomirski wrote:
> > >> On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner
>
On Wed, Aug 14, 2013 at 11:14:37PM -0700, Andy Lutomirski wrote:
> On Wed, Aug 14, 2013 at 11:01 PM, Dave Chinner wrote:
> > On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy Lutomirski wrote:
> >> On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner wrote:
> >> > On Wed, Aug 14, 2013 at 09:11:01PM -0400,
On Wed, Aug 14, 2013 at 11:18 PM, David Lang wrote:
> On Wed, 14 Aug 2013, Andy Lutomirski wrote:
>
>>> The big problem with this approach is that not doing the
>>> timestamp update on page faults is going to break the inode change
>>> version counting because for ext4, btrfs and XFS it takes a
>>
On Wed, 14 Aug 2013, Andy Lutomirski wrote:
The big problem with this approach is that not doing the
timestamp update on page faults is going to break the inode change
version counting because for ext4, btrfs and XFS it takes a
transaction to bump that counter. NFS needs to know the moment a
fil
On Wed, Aug 14, 2013 at 11:01 PM, Dave Chinner wrote:
> On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy Lutomirski wrote:
>> On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner wrote:
>> > On Wed, Aug 14, 2013 at 09:11:01PM -0400, Theodore Ts'o wrote:
>> >> On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy
On Wed, Aug 14, 2013 at 09:32:13PM -0700, Andy Lutomirski wrote:
> On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner wrote:
> > On Wed, Aug 14, 2013 at 09:11:01PM -0400, Theodore Ts'o wrote:
> >> On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy Lutomirski wrote:
> >> > > It would be better to write zero
On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner wrote:
> On Wed, Aug 14, 2013 at 09:11:01PM -0400, Theodore Ts'o wrote:
>> On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy Lutomirski wrote:
>> > > It would be better to write zeros to it, so we aren't measuring the
>> > > cost of the unwritten->written
On Wed, Aug 14, 2013 at 07:24:01PM -0700, Andi Kleen wrote:
> > And FWIW, it's no secret that XFS has more per-operation overhead
> > than ext4 through the write path when it comes to allocation, so
> > it's no surprise that on a workload that is highly dependent on
> > allocation overhead that ext
> And FWIW, it's no secret that XFS has more per-operation overhead
> than ext4 through the write path when it comes to allocation, so
> it's no surprise that on a workload that is highly dependent on
> allocation overhead that ext4 is a bit faster
This cannot explain a worse scaling curve tho
On Wed, Aug 14, 2013 at 09:11:01PM -0400, Theodore Ts'o wrote:
> On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy Lutomirski wrote:
> > > It would be better to write zeros to it, so we aren't measuring the
> > > cost of the unwritten->written conversion.
> >
> > At the risk of beating a dead horse,
On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy Lutomirski wrote:
> > It would be better to write zeros to it, so we aren't measuring the
> > cost of the unwritten->written conversion.
>
> At the risk of beating a dead horse, how hard would it be to defer
> this part until writeback?
Part of the w
On Wed, Aug 14, 2013 at 10:10:07AM -0700, Dave Hansen wrote:
> We talked a little about this issue in this thread:
>
> http://marc.info/?l=linux-mm&m=137573185419275&w=2
>
> but I figured I'd follow up with a full comparison. ext4 is about 20%
> slower in handling write page faults than ex
On Wed, Aug 14, 2013 at 4:06 PM, Theodore Ts'o wrote:
> On Wed, Aug 14, 2013 at 01:50:02PM -0700, Dave Hansen wrote:
>>
>> Would a plain old fallocate() do the trick, or does it actually need
>> zeros written to it?
>
> It would be better to write zeros to it, so we aren't measuring the
> cost of
On Wed, Aug 14, 2013 at 01:50:02PM -0700, Dave Hansen wrote:
>
> Would a plain old fallocate() do the trick, or does it actually need
> zeros written to it?
It would be better to write zeros to it, so we aren't measuring the
cost of the unwritten->written conversion.
We could do a different test
On 08/14/2013 12:43 PM, Theodore Ts'o wrote:
> Thanks dave for doing this comparison. Is there any chance you can
> check whether lockstats shows anything interesting?
>
>> Test case is this:
>>
>>
>> https://github.com/antonblanchard/will-it-scale/blob/master/tests/page_fault3.c
>
> One i
Thanks dave for doing this comparison. Is there any chance you can
check whether lockstats shows anything interesting?
> Test case is this:
>
>
> https://github.com/antonblanchard/will-it-scale/blob/master/tests/page_fault3.c
One interesting thing about the test case. It looks like the
39 matches
Mail list logo
