On Fri, Mar 16, 2018 at 11:55:30AM +0300, Kirill Tkhai wrote:
> On 16.03.2018 02:03, Dave Chinner wrote:
> > On Thu, Mar 15, 2018 at 10:28:43PM +0300, Kirill Tkhai wrote:
> >> On 15.03.2018 20:49, Michal Hocko wrote:
> >>> On Thu 15-03-1
On Fri, Mar 16, 2018 at 11:55:30AM +0300, Kirill Tkhai wrote:
> On 16.03.2018 02:03, Dave Chinner wrote:
> > On Thu, Mar 15, 2018 at 10:28:43PM +0300, Kirill Tkhai wrote:
> >> On 15.03.2018 20:49, Michal Hocko wrote:
> >>> On Thu 15-03-1
cgs at this level.
So, is there a problem you are actually trying to fix, or is this
simply a "I don't understand how the superblock shrinkers work,
please explain" patch?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
cgs at this level.
So, is there a problem you are actually trying to fix, or is this
simply a "I don't understand how the superblock shrinkers work,
please explain" patch?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Fri, Mar 02, 2018 at 04:08:24PM -0600, Eric Sandeen wrote:
>
>
> On 3/2/18 3:57 PM, Dave Chinner wrote:
> > On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote:
> >> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote:
> >>> Th
On Fri, Mar 02, 2018 at 04:08:24PM -0600, Eric Sandeen wrote:
>
>
> On 3/2/18 3:57 PM, Dave Chinner wrote:
> > On Fri, Mar 02, 2018 at 09:24:01AM -0800, Darrick J. Wong wrote:
> >> On Fri, Mar 02, 2018 at 10:30:13PM +0900, Masanari Iida wrote:
> >>> Th
erformance
> > and scalability.
> >
> > -Refer to the documentation at http://oss.sgi.com/projects/xfs/
> > +Refer to the documentation at https://xfs.wiki.kernel.org/
Did I miss a memo?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
t; and scalability.
> >
> > -Refer to the documentation at http://oss.sgi.com/projects/xfs/
> > +Refer to the documentation at https://xfs.wiki.kernel.org/
Did I miss a memo?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
.
Can you please fix up your patch set sending again?
-Dave.
--
Dave Chinner
da...@fromorbit.com
.
Can you please fix up your patch set sending again?
-Dave.
--
Dave Chinner
da...@fromorbit.com
/inode.c | 38 ++
> fs/notify/fsnotify.c | 9 +-
> fs/quota/dquot.c | 14 +-
> fs/super.c | 7 +-
> include/linux/dlock-list.h | 263 +++++++
> include/linux/fs.h | 8 +-
> lib/Makefile | 2 +-
> lib/dlock-list.c | 333
> +
> 10 files changed, 638 insertions(+), 54 deletions(-)
> create mode 100644 include/linux/dlock-list.h
> create mode 100644 lib/dlock-list.c
>
> --
> 1.8.3.1
>
>
--
Dave Chinner
da...@fromorbit.com
/inode.c | 38 ++
> fs/notify/fsnotify.c | 9 +-
> fs/quota/dquot.c | 14 +-
> fs/super.c | 7 +-
> include/linux/dlock-list.h | 263 +++++++
> include/linux/fs.h | 8 +-
> lib/Makefile | 2 +-
> lib/dlock-list.c | 333
> +
> 10 files changed, 638 insertions(+), 54 deletions(-)
> create mode 100644 include/linux/dlock-list.h
> create mode 100644 lib/dlock-list.c
>
> --
> 1.8.3.1
>
>
--
Dave Chinner
da...@fromorbit.com
ly not waiting for IO completion
here, instead leaving it to the completion code to free the struct
dio and pass the completion status to the AIO code appropriately.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
on
here, instead leaving it to the completion code to free the struct
dio and pass the completion status to the AIO code appropriately.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Feb 21, 2018 at 11:56:22AM +0200, Igor Stoppa wrote:
> On 21/02/18 03:36, Dave Chinner wrote:
> > On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote:
> >> On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote:
> >>> FWIW, I'm not wanti
On Wed, Feb 21, 2018 at 11:56:22AM +0200, Igor Stoppa wrote:
> On 21/02/18 03:36, Dave Chinner wrote:
> > On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote:
> >> On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote:
> >>> FWIW, I'm not wanti
On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote:
> On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote:
> > FWIW, I'm not wanting to use it to replace static variables. All the
> > structures are dynamically allocated right now, and get assigned to
> &
On Tue, Feb 20, 2018 at 03:56:00PM -0800, Matthew Wilcox wrote:
> On Wed, Feb 21, 2018 at 08:36:04AM +1100, Dave Chinner wrote:
> > FWIW, I'm not wanting to use it to replace static variables. All the
> > structures are dynamically allocated right now, and get assigned to
> &
On Tue, Feb 20, 2018 at 08:03:49PM +0200, Igor Stoppa wrote:
>
>
> On 20/02/18 03:21, Dave Chinner wrote:
> > On Mon, Feb 12, 2018 at 03:32:36PM -0800, Kees Cook wrote:
> >> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa <igor.sto...@huawei.com>
> >>
On Tue, Feb 20, 2018 at 08:03:49PM +0200, Igor Stoppa wrote:
>
>
> On 20/02/18 03:21, Dave Chinner wrote:
> > On Mon, Feb 12, 2018 at 03:32:36PM -0800, Kees Cook wrote:
> >> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa
> >> wrote:
> >>> This patch
e is meant for data that doesn't need
> > further modifications after initialization.
>
> This series came up in discussions with Dave Chinner (and Matthew
> Wilcox, already part of the discussion, and others) at LCA. I wonder
> if XFS would make a good initial user of t
hat doesn't need
> > further modifications after initialization.
>
> This series came up in discussions with Dave Chinner (and Matthew
> Wilcox, already part of the discussion, and others) at LCA. I wonder
> if XFS would make a good initial user of this, as it could allocate
> a
eek) I'll update the fsmark
aio patches I have and retest this. The code looks pretty similar to
the last "generic aio fsync" patch I wrote, so I'm guessing that the
results will be pretty similar, too.
It would be good to finally get this implemented in the kernel...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
eek) I'll update the fsmark
aio patches I have and retest this. The code looks pretty similar to
the last "generic aio fsync" patch I wrote, so I'm guessing that the
results will be pretty similar, too.
It would be good to finally get this implemented in the kernel...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
lay...@redhat.com>
> Reviewed-by: Jan Kara <j...@suse.cz>
Documentation helps a lot in understanding all this. Thanks for
adding it into the patch!
Acked-by: Dave Chinner <dchin...@redhat.com>
--
Dave Chinner
da...@fromorbit.com
value and try again.
>
> This method allows us to avoid incrementing the counter on writes (and
> dirtying the metadata) under typical workloads. We only need to increment
> if it has been queried since it was last changed.
>
> Signed-off-by: Jeff Layton
> Reviewed-by: Jan Kara
D
.w...@oracle.com>
Acked-by: Dave Chinner <dchin...@redhat.com>
--
Dave Chinner
da...@fromorbit.com
On Tue, Jan 09, 2018 at 09:10:57AM -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> If XFS_ILOG_CORE is already set then go ahead and increment it.
>
> Signed-off-by: Jeff Layton
> Acked-by: Darrick J. Wong
Acked-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
On Tue, Jan 09, 2018 at 09:10:54AM -0500, Jeff Layton wrote:
> From: Jeff Layton <jlay...@redhat.com>
>
> Signed-off-by: Jeff Layton <jlay...@redhat.com>
> Acked-by: Darrick J. Wong <darrick.w...@oracle.com>
Looks ok, but I haven't tested it at all.
Acked-by: Dav
On Tue, Jan 09, 2018 at 09:10:54AM -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> Signed-off-by: Jeff Layton
> Acked-by: Darrick J. Wong
Looks ok, but I haven't tested it at all.
Acked-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
). IOWs, we need a lot more than a
"hello world" test to be able to verify filesystems interact with
IMA properly. e.g. how does it behave at ENOSPC?
How do you test that IMA is fully working and has no regressions
during your development? I'm sure there's more than a "hello world"
test for that
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
). IOWs, we need a lot more than a
"hello world" test to be able to verify filesystems interact with
IMA properly. e.g. how does it behave at ENOSPC?
How do you test that IMA is fully working and has no regressions
during your development? I'm sure there's more than a "hello world"
test for that
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ng very unfriendly to developers. We've all been scarred by
lockdep at one time or another and so there's a fair bit of
resistance to repeating past mistakes and allowing lockdep to
inflict more scars on us
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ere's a fair bit of
resistance to repeating past mistakes and allowing lockdep to
inflict more scars on us
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
return false;
> if (!IS_DAX(page->mapping->host))
> return false;
> return true;
> }
This is likely to be a problem in lots more places if we have to
treat "has page been truncated away" race checks on dax mappings
differently to page cache mappings. This smells of a whack-a-mole
style bandaid to me
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
false;
> if (!IS_DAX(page->mapping->host))
> return false;
> return true;
> }
This is likely to be a problem in lots more places if we have to
treat "has page been truncated away" race checks on dax mappings
differently to page cache mappings. This smells of a whack-a-mole
style bandaid to me
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
to work
> properly for these modified functions.
>
> Miscellanea:
>
> o Remove extra trailing ; and blank line from xfs_agf_verify
>
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
....
XFS bits look fine.
Acked-by: Dave Chinner <dchin...@redhat.com>
--
Dave Chinner
da...@fromorbit.com
to work
> properly for these modified functions.
>
> Miscellanea:
>
> o Remove extra trailing ; and blank line from xfs_agf_verify
>
> Signed-off-by: Joe Perches
> ---
XFS bits look fine.
Acked-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
inode: inode to check
> @@ -248,7 +250,7 @@ inode_query_iversion(struct inode *inode)
> {
> u64 cur, old, new;
>
> - cur = atomic64_read(>i_version);
> + cur = inode_peek_iversion_raw(inode);
> for (;;) {
> /* If flag is already set, then no need to swap */
> if (cur & I_VERSION_QUERIED)
cmpxchg in this loop needs a release barrier so everyone will
see the change on load?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
inode: inode to check
> @@ -248,7 +250,7 @@ inode_query_iversion(struct inode *inode)
> {
> u64 cur, old, new;
>
> - cur = atomic64_read(>i_version);
> + cur = inode_peek_iversion_raw(inode);
> for (;;) {
> /* If flag is already set, then no need to swap */
> if (cur & I_VERSION_QUERIED)
cmpxchg in this loop needs a release barrier so everyone will
see the change on load?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
, so maybe it would be better to split relatively isolated
functionality like this out while it's being reworked and you're
already touching every file that uses it?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
olated
functionality like this out while it's being reworked and you're
already touching every file that uses it?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Dec 13, 2017 at 07:10:22PM -0500, Jeff Layton wrote:
> On Thu, 2017-12-14 at 10:25 +1100, Dave Chinner wrote:
> > So now I've looked at the last patch .
> >
> > On Thu, Dec 14, 2017 at 09:48:37AM +1100, Dave Chinner wrote:
> > > On Wed, Dec 13, 2017 at
On Wed, Dec 13, 2017 at 07:10:22PM -0500, Jeff Layton wrote:
> On Thu, 2017-12-14 at 10:25 +1100, Dave Chinner wrote:
> > So now I've looked at the last patch .
> >
> > On Thu, Dec 14, 2017 at 09:48:37AM +1100, Dave Chinner wrote:
> > > On Wed, Dec 13, 2017 at
On Thu, Dec 14, 2017 at 12:00:52AM +0100, Luis R. Rodriguez wrote:
> On Thu, Dec 14, 2017 at 08:50:13AM +1100, Dave Chinner wrote:
> > On Tue, Dec 12, 2017 at 04:45:15PM -0800, Luis R. Rodriguez wrote:
> > > This should make it easy to run these separately or exclude them.
>
On Thu, Dec 14, 2017 at 12:00:52AM +0100, Luis R. Rodriguez wrote:
> On Thu, Dec 14, 2017 at 08:50:13AM +1100, Dave Chinner wrote:
> > On Tue, Dec 12, 2017 at 04:45:15PM -0800, Luis R. Rodriguez wrote:
> > > This should make it easy to run these separately or exclude them.
>
So now I've looked at the last patch .
On Thu, Dec 14, 2017 at 09:48:37AM +1100, Dave Chinner wrote:
> On Wed, Dec 13, 2017 at 09:20:12AM -0500, Jeff Layton wrote:
> > From: Jeff Layton <jlay...@redhat.com>
> >
> > Signed-off-by: Jeff Layton <jlay...@redhat.c
So now I've looked at the last patch .
On Thu, Dec 14, 2017 at 09:48:37AM +1100, Dave Chinner wrote:
> On Wed, Dec 13, 2017 at 09:20:12AM -0500, Jeff Layton wrote:
> > From: Jeff Layton
> >
> > Signed-off-by: Jeff Layton
> > ---
> > fs/xfs/libxfs/xfs_
3GiB (69.0GB), run=61-61msec
>
> noivers:
> WRITE: bw=117MiB/s (123MB/s), 14.2MiB/s-15.2MiB/s (14.9MB/s-15.9MB/s),
> io=68.7GiB (73.8GB), run=61-61msec
>
> So, I see some performance degradation with -o iversion compared to not
> having it enabled (maybe due to th
3GiB (69.0GB), run=61-61msec
>
> noivers:
> WRITE: bw=117MiB/s (123MB/s), 14.2MiB/s-15.2MiB/s (14.9MB/s-15.9MB/s),
> io=68.7GiB (73.8GB), run=61-61msec
>
> So, I see some performance degradation with -o iversion compared to not
> having it enabled (maybe due to th
; if (!(ip->i_itemp->ili_item.li_desc->lid_flags & XFS_LID_DIRTY) &&
> IS_I_VERSION(VFS_I(ip))) {
> - VFS_I(ip)->i_version++;
> + inode_inc_iversion(VFS_I(ip));
> flags |= XFS_ILOG_CORE;
> }
And isn't this a case of "filesystem managed" iversion behaviour?
Basically, I can't make head or tail of why the different API
functions are used here
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
id_flags & XFS_LID_DIRTY) &&
> IS_I_VERSION(VFS_I(ip))) {
> - VFS_I(ip)->i_version++;
> + inode_inc_iversion(VFS_I(ip));
> flags |= XFS_ILOG_CORE;
> }
And isn't this a case of "filesystem managed" iversion behaviour?
Basically, I can't make head or tail of why the different API
functions are used here
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
run or not.
xfs/096 2s ... [not run] Requires older mkfs without strict input checks: the
last supported version of xfsprogs is 4.5.
Why are you trying to add groups to define tests that not_run
correctly on systems they aren't supported on?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
run or not.
xfs/096 2s ... [not run] Requires older mkfs without strict input checks: the
last supported version of xfsprogs is 4.5.
Why are you trying to add groups to define tests that not_run
correctly on systems they aren't supported on?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Dec 12, 2017 at 04:45:19PM -0800, Luis R. Rodriguez wrote:
> XFS error injection requires CONFIG_XFS_DEBUG and not all kernels
> have this enabled.
NAK. this should be automatically detected by the tests and they
_not_run when support is not available.
Cheers,
Dave.
--
Dave Chin
On Tue, Dec 12, 2017 at 04:45:19PM -0800, Luis R. Rodriguez wrote:
> XFS error injection requires CONFIG_XFS_DEBUG and not all kernels
> have this enabled.
NAK. this should be automatically detected by the tests and they
_not_run when support is not available.
Cheers,
Dave.
--
Dave Chin
y includes all the tests that use
external logs. It would be better to tag all the tests that exercise
the log with "log" rather than create some new group that doesn't
really provide any added benefit
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
e tests that use
external logs. It would be better to tag all the tests that exercise
the log with "log" rather than create some new group that doesn't
really provide any added benefit
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
a can differentiate between UIDs and names beginning with
numbers
So from that perspective, NAK.
IF there are distros not allowing usernames to start with digits,
then this test needs a _requires check and to _notrun on those
systems.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
iate between UIDs and names beginning with
numbers
So from that perspective, NAK.
IF there are distros not allowing usernames to start with digits,
then this test needs a _requires check and to _notrun on those
systems.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Dec 11, 2017 at 02:12:28PM -0800, Joe Perches wrote:
> On Tue, 2017-12-12 at 08:43 +1100, Dave Chinner wrote:
> > On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote:
> > > On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> > > > 1. Usin
On Mon, Dec 11, 2017 at 02:12:28PM -0800, Joe Perches wrote:
> On Tue, 2017-12-12 at 08:43 +1100, Dave Chinner wrote:
> > On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote:
> > > On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> > > > 1. Usin
On Sun, Dec 10, 2017 at 08:23:15PM -0800, Matthew Wilcox wrote:
> On Mon, Dec 11, 2017 at 10:57:45AM +1100, Dave Chinner wrote:
> > i.e. the fact the cmpxchg failed may not have anything to do with a
> > race condtion - it failed because the slot wasn't empty like
On Sun, Dec 10, 2017 at 08:23:15PM -0800, Matthew Wilcox wrote:
> On Mon, Dec 11, 2017 at 10:57:45AM +1100, Dave Chinner wrote:
> > i.e. the fact the cmpxchg failed may not have anything to do with a
> > race condtion - it failed because the slot wasn't empty like
On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote:
> On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> > 1. Using lockdep_set_novalidate_class() for anything other
> > than device->mutex will throw checkpatch warnings. Nice. (*)
> []
> > (*)
On Sat, Dec 09, 2017 at 09:00:18AM -0800, Joe Perches wrote:
> On Sat, 2017-12-09 at 09:36 +1100, Dave Chinner wrote:
> > 1. Using lockdep_set_novalidate_class() for anything other
> > than device->mutex will throw checkpatch warnings. Nice. (*)
> []
> > (*)
On Fri, Dec 08, 2017 at 03:01:31PM -0800, Matthew Wilcox wrote:
> On Thu, Dec 07, 2017 at 11:38:43AM +1100, Dave Chinner wrote:
> > > > cmpxchg is for replacing a known object in a store - it's not really
> > > > intended for doing initial inserts after a lookup tells
On Fri, Dec 08, 2017 at 03:01:31PM -0800, Matthew Wilcox wrote:
> On Thu, Dec 07, 2017 at 11:38:43AM +1100, Dave Chinner wrote:
> > > > cmpxchg is for replacing a known object in a store - it's not really
> > > > intended for doing initial inserts after a lookup tells
ructure just to add lockdep validation
to a tree that doesn't actually need any extra locking validation...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ructure just to add lockdep validation
to a tree that doesn't actually need any extra locking validation...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
Who-ever adds semaphore checking to lockdep can add those
annotations. The externalisation of the development cost of new
lockdep functionality is one of the problems here.
-Dave.
(*) checkpatch.pl is considered mostly harmful round here, too,
but that's another rant
(**) the frequent occurrence of "core code/devs aren't held to the
same rules/standard as everyone else" is another rant I have stored
up for a rainy day.
--
Dave Chinner
da...@fromorbit.com
Who-ever adds semaphore checking to lockdep can add those
annotations. The externalisation of the development cost of new
lockdep functionality is one of the problems here.
-Dave.
(*) checkpatch.pl is considered mostly harmful round here, too,
but that's another rant
(**) the frequent occurrence of "core code/devs aren't held to the
same rules/standard as everyone else" is another rant I have stored
up for a rainy day.
--
Dave Chinner
da...@fromorbit.com
On Fri, Dec 08, 2017 at 01:45:52PM +0900, Byungchul Park wrote:
> On Fri, Dec 08, 2017 at 09:22:16AM +1100, Dave Chinner wrote:
> > On Thu, Dec 07, 2017 at 11:06:34AM -0500, Theodore Ts'o wrote:
> > > On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> > >
On Fri, Dec 08, 2017 at 01:45:52PM +0900, Byungchul Park wrote:
> On Fri, Dec 08, 2017 at 09:22:16AM +1100, Dave Chinner wrote:
> > On Thu, Dec 07, 2017 at 11:06:34AM -0500, Theodore Ts'o wrote:
> > > On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> > >
7] [] ?
> kmem_cache_alloc+0x35/0x1d0
>
> [Mon Dec 4 21:08:21 2017] [] ? getname_flags+0x4f/0x1a0
>
> [Mon Dec 4 21:08:21 2017] [] filename_lookup+0x2b/0xc0
>
> [Mon Dec 4 21:08:21 2017] []
> user_path_at_empty+0x67/0xc0
>
> [Mon Dec 4 21:08:21 2017] [] user_path_at+0x11/0x20
>
> [Mon Dec 4 21:08:21 2017] [] vfs_fstatat+0x63/0xc0
>
> [Mon Dec 4 21:08:21 2017] [] SYSC_newlstat+0x31/0x60
>
> [Mon Dec 4 21:08:21 2017] [] ? vfs_readdir+0x8c/0xe0
>
> [Mon Dec 4 21:08:21 2017] [] ? SyS_getdents+0xfd/0x120
>
> [Mon Dec 4 21:08:21 2017] [] SyS_newlstat+0xe/0x10
>
> [Mon Dec 4 21:08:21 2017] []
> system_call_fastpath+0x16/0x1b
--
Dave Chinner
da...@fromorbit.com
7] [] ?
> kmem_cache_alloc+0x35/0x1d0
>
> [Mon Dec 4 21:08:21 2017] [] ? getname_flags+0x4f/0x1a0
>
> [Mon Dec 4 21:08:21 2017] [] filename_lookup+0x2b/0xc0
>
> [Mon Dec 4 21:08:21 2017] []
> user_path_at_empty+0x67/0xc0
>
> [Mon Dec 4 21:08:21 2017] [] user_path_at+0x11/0x20
>
> [Mon Dec 4 21:08:21 2017] [] vfs_fstatat+0x63/0xc0
>
> [Mon Dec 4 21:08:21 2017] [] SYSC_newlstat+0x31/0x60
>
> [Mon Dec 4 21:08:21 2017] [] ? vfs_readdir+0x8c/0xe0
>
> [Mon Dec 4 21:08:21 2017] [] ? SyS_getdents+0xfd/0x120
>
> [Mon Dec 4 21:08:21 2017] [] SyS_newlstat+0xe/0x10
>
> [Mon Dec 4 21:08:21 2017] []
> system_call_fastpath+0x16/0x1b
--
Dave Chinner
da...@fromorbit.com
problem, you'd be happier, right?
I'd be much happier if it wasn't turned on by default in the first
place. We gave plenty of warnings that there were still unsolved
false positive problems with the new checks in the storage stack.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
problem, you'd be happier, right?
I'd be much happier if it wasn't turned on by default in the first
place. We gave plenty of warnings that there were still unsolved
false positive problems with the new checks in the storage stack.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
hich means
it has zero coverage of the entire XFS metadata buffer subsystem and
the complex locking orders we have for metadata updates.
Put simply: lockdep doesn't provide me with any benefit, so I don't
use it...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
hich means
it has zero coverage of the entire XFS metadata buffer subsystem and
the complex locking orders we have for metadata updates.
Put simply: lockdep doesn't provide me with any benefit, so I don't
use it...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 07:44:04PM +1100, Dave Chinner wrote:
> > On Tue, Dec 05, 2017 at 08:45:49PM -0800, Matthew Wilcox wrote:
> > > That said, using xa_cmpxchg() in the dquot code looked like the right
> &g
On Wed, Dec 06, 2017 at 06:06:48AM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 07:44:04PM +1100, Dave Chinner wrote:
> > On Tue, Dec 05, 2017 at 08:45:49PM -0800, Matthew Wilcox wrote:
> > > That said, using xa_cmpxchg() in the dquot code looked like the right
> &g
On Tue, Dec 05, 2017 at 08:45:49PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 02:14:56PM +1100, Dave Chinner wrote:
> > > The other conversions use the normal API instead of the advanced API, so
> > > all of this gets hidden away. For example, the inode cache d
On Tue, Dec 05, 2017 at 08:45:49PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 02:14:56PM +1100, Dave Chinner wrote:
> > > The other conversions use the normal API instead of the advanced API, so
> > > all of this gets hidden away. For example, the inode cache d
On Tue, Dec 05, 2017 at 06:02:08PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 12:36:48PM +1100, Dave Chinner wrote:
> > > - if (radix_tree_preload(GFP_NOFS))
> > > - return -ENOMEM;
> > > -
> > > INIT_LIST_HEAD(>list_node);
> >
On Tue, Dec 05, 2017 at 06:02:08PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 12:36:48PM +1100, Dave Chinner wrote:
> > > - if (radix_tree_preload(GFP_NOFS))
> > > - return -ENOMEM;
> > > -
> > > INIT_LIST_HEAD(>list_node);
> >
On Tue, Dec 05, 2017 at 06:05:15PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> > On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > > From: Matthew Wilcox <mawil...@microsoft.com>
> > >
On Tue, Dec 05, 2017 at 06:05:15PM -0800, Matthew Wilcox wrote:
> On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> > On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > > From: Matthew Wilcox
> > >
> > > I looked through some
his time.
-Dave.
>
> > -Original Message-----
> > From: Dave Chinner [mailto:da...@fromorbit.com]
> > Sent: Tuesday, December 5, 2017 8:51 PM
> > To: Matthew Wilcox <wi...@infradead.org>
> > Cc: Matthew Wilcox <mawil...@microsoft.com>; Ross Zwisler
> >
his time.
-Dave.
>
> > -Original Message-----
> > From: Dave Chinner [mailto:da...@fromorbit.com]
> > Sent: Tuesday, December 5, 2017 8:51 PM
> > To: Matthew Wilcox
> > Cc: Matthew Wilcox ; Ross Zwisler
> > ; Jens Axboe ; Rehas
> > Sachdeva ; linux...
On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox <mawil...@microsoft.com>
> >
> > I looked through some notes and decided this was version 4 of the XArray.
&g
On Wed, Dec 06, 2017 at 12:45:49PM +1100, Dave Chinner wrote:
> On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> > From: Matthew Wilcox
> >
> > I looked through some notes and decided this was version 4 of the XArray.
> > Last posted two weeks ago, t
On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox <mawil...@microsoft.com>
>
> I looked through some notes and decided this was version 4 of the XArray.
> Last posted two weeks ago, this version includes a *lot* of changes.
> I'd like
On Tue, Dec 05, 2017 at 04:40:46PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox
>
> I looked through some notes and decided this was version 4 of the XArray.
> Last posted two weeks ago, this version includes a *lot* of changes.
> I'd like to thank Dave Chinner f
tions. Turning that around
so that a larger XFS structure and algorithm is now protected by an
opaque internal lock from generic storage structure the forms part
of the larger structure seems like a bad design pattern to me...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
round
so that a larger XFS structure and algorithm is now protected by an
opaque internal lock from generic storage structure the forms part
of the larger structure seems like a bad design pattern to me...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ocking
> operation itself. On the other hand, the performance gain will be
> noticeable when the lock is contended. I will ran some performance
> measurement and report the results later.
Given the extreme fuzziness of the benefit of manual prefetching,
you'll need to:
a) document the test
b) run the test on mulitple architectures
c) run the test on mulitple different CPU models within
the x86-64 architecture
d) show that it works in general for a majority of the
platforms and CPUs you benched, and not just for your
microbenchmark.
Basically, if there's historic context with people like Ingo saying
"prefetching is toxic" then there's a bloody high bar you need to
get over to add manual prefetching anywhere...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
the existing
> >>> list_empty() check within the lock critical region.
> >> But it sounds like Dave thinks that unlocked check should be removed?
> >>
> >> How does this adendum look?
> >>
> >> From: Andrew Morton
> >> Subject:
te - that
tasks *will freeze when holding VFS locks* - and so the cgroup
freezer is broken by design if it requires tasks to be frozen
without holding any VFS/filesystem lock context. So I wouldn't
really worry about the cgroup freezer
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
te - that
tasks *will freeze when holding VFS locks* - and so the cgroup
freezer is broken by design if it requires tasks to be frozen
without holding any VFS/filesystem lock context. So I wouldn't
really worry about the cgroup freezer
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
601 - 700 of 3916 matches
Mail list logo
