On Fri, May 10, 2013 at 02:47:35PM +0900, OGAWA Hirofumi wrote:
Dave Chinner da...@fromorbit.com writes:
tux3:
Operation CountAvgLatMaxLat
NTCreateX1477980 0.00312.944
ReadX2316653
as efficiently as possible?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On Tue, May 14, 2013 at 03:04:40PM -0700, Zach Brown wrote:
On Wed, May 15, 2013 at 07:42:51AM +1000, Dave Chinner wrote:
On Tue, May 14, 2013 at 02:15:22PM -0700, Zach Brown wrote:
I'm going to keep hacking away at this. My next step is to get ext4
supporting .copy_range, probably
Chinner dchin...@redhat.com
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
is the shrinker infrastructure supposed to do with a
random error code?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
devices does not deliver any improved performance for
single-threaded writes. (Have not thoroughly tested this
configuration fully with multiple writers, though.)
Of course not - you are CPU bound and nothing you do to the storage
will change that.
Cheers,
Dave.
--
Dave Chinner
da
On Tue, Sep 03, 2013 at 11:38:27AM -0700, Tim Chen wrote:
On Sat, 2013-08-31 at 19:00 +1000, Dave Chinner wrote:
On Fri, Aug 30, 2013 at 09:21:34AM -0700, Tim Chen wrote:
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
diff --git a/fs/super.c b/fs/super.c
index 73d0952
current and future needs...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
. when there are lots of memcgs) then such a threshold might
only be appropriate for caches that are not memcg controlled. In
that case, handling it in the shrinker infrastructure itself is a
much better idea than hacking thresholds into individual shrinker
callouts.
Cheers,
Dave.
--
Dave Chinner
da
the needless contentions. That should make the memcg guys happy by
not holding any extra free entries.
Ok, that's good to know, and it further indicates that it is the
-count_objects() callout that is the issue, not the
scanning/freeing.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
for
shrink_slab:shrink_slab_node. An because shrink_slab_node() has one
less callout per batch iteration, there is an overall reduction in
the number of grab_super_passive calls from the shrinker. Worst case
is no change, best case is a 50% reduction in the number of calls.
Cheers,
Dave.
--
Dave Chinner
da
On Fri, Aug 30, 2013 at 09:21:34AM -0700, Tim Chen wrote:
On Fri, 2013-08-30 at 11:40 +1000, Dave Chinner wrote:
The new shrinker infrastructure has a -count_objects() callout to
specifically return the number of objects in the cache.
shrink_slab_node() can check that return value
basically resigned myself to
spending a day a week over the next few months cleaning this cruft
up. We're not going to fix the problem in a single patchset for
3.11...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
companies are strange some times...
Didn't we learn this lesson already with POHMELFS? i.e. that dumping
filesystem code in staging on the assumption the community will
fix it up when nobody in the community uses or can even test that
filesystem is a broken development model
Cheers,
Dave.
--
Dave
On Tue, Jul 02, 2013 at 08:28:42PM -0700, Linus Torvalds wrote:
On Tue, Jul 2, 2013 at 8:07 PM, Dave Chinner da...@fromorbit.com wrote:
Then that test would become
if (wbc-sync_mode == WB_SYNC_SINGLE) {
instead, and now sync_mode would actually describe what mode of
syncing
...@oss.sgi.com list. There are far
more people than just the maintainer that can triage problems,
answer questions and review patches...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On Wed, Jul 03, 2013 at 10:14:41AM +0200, Yann Droneaud wrote:
Hi,
Le 03.07.2013 08:40, Dave Chinner a écrit :
On Tue, Jul 02, 2013 at 05:00:47PM +0200, Yann Droneaud wrote:
This patch changes type of x...@oss.sgi.com
The output of ./scripts/get_maintainer.pl is
modified to report x
On Wed, Jul 03, 2013 at 11:36:39AM +0200, Yann Droneaud wrote:
Le 03.07.2013 11:24, Dave Chinner a écrit :
On Wed, Jul 03, 2013 at 10:14:41AM +0200, Yann Droneaud wrote:
Le 03.07.2013 08:40, Dave Chinner a écrit :
On Tue, Jul 02, 2013 at 05:00:47PM +0200, Yann Droneaud wrote:
This patch
On Tue, Jul 02, 2013 at 02:44:27PM +0200, Michal Hocko wrote:
On Tue 02-07-13 22:19:47, Dave Chinner wrote:
[...]
Ok, so it's been leaked from a dispose list somehow. Thanks for the
info, Michal, it's time to go look at the code
OK, just in case we will need it, I am keeping
On Wed, Jul 03, 2013 at 06:40:40PM +, Dilger, Andreas wrote:
On 2013/03/07 12:12 PM, Greg KH g...@kroah.com wrote:
On Wed, Jul 03, 2013 at 01:29:41PM +1000, Dave Chinner wrote:
On Tue, Jul 02, 2013 at 06:01:11PM -0700, Greg KH wrote:
For this filesystem, it seems that they don't have
assuming that the application is actually doing 1MB sized and
aligned IOs like was mentioned, because both methods are directly
dispatching and then waiting for IO completion.
What filesystem is in use here?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send
On Wed, Jul 03, 2013 at 08:31:03PM -0400, Mathieu Desnoyers wrote:
* Dave Chinner (da...@fromorbit.com) wrote:
On Wed, Jul 03, 2013 at 10:53:08AM -0400, Jeff Moyer wrote:
Mel Gorman mgor...@suse.de writes:
I just tried replacing my sync_file_range()+fadvise() calls and
instead
to this? There are many loops that
actually require list_del_init() rather than list_del()...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
immature at this stage.
More review is always welcome and I'm committed to address issues.
IMO, supporting a real block based filesystem like ext4 or XFS and
demonstrating that everything works is necessary before we go any
further...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
hundreds of synchronous operations per
barrier_deadline_ms..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
for them
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
with GFP_NOFS, because GFP_KERNEL allocations
are almost guaranteed to deadlock on the locked pages this path
already holds
Need I say more?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Tue, Jul 23, 2013 at 02:58:58PM -0700, Jeremy Allison wrote:
On Tue, Jul 23, 2013 at 05:10:27PM +1000, Dave Chinner wrote:
So, we are nesting up to 32 page locks here. That's bad. And we are
nesting kmap() calls for all the pages individually - is that even
safe to do?
So, what
On Mon, Jul 22, 2013 at 05:06:01AM +0100, Al Viro wrote:
On Mon, Jul 22, 2013 at 11:25:17AM +1000, Dave Chinner wrote:
I'll just point out that it can make the whole thing worse, too.
For example, for ext3/4, the tmpfile being created has to be added
to the orphan inode list which
by blocking operations inside
shrinker functions (e.g. mutex_lock()).
So what you are saying is that kswapd is having problems with
getting blocked on locks held by processes in direct reclaim?
What are the stack traces that demonstrate such a dependency loop?
Cheers,
Dave.
--
Dave Chinner
da
lock_flags)
If you are going to change the return type to bool, then you should
also remove the manual !! conversions to a boolean return and let
the compiler do it in the most optimal way.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line
On Fri, Jun 06, 2014 at 07:39:30PM -0700, Joe Perches wrote:
On Fri, 2014-06-06 at 21:41 -0400, Pranith Kumar wrote:
On 06/06/2014 08:59 PM, Pranith Kumar wrote:
On 06/06/2014 08:18 PM, Dave Chinner wrote:
If you are going to change the return type to bool, then you should
also remove
Foster (1):
xfs: initialize default acls for -tmpfile()
Dave Chinner (2):
xfs: fully support v5 format filesystems
xfs: remote attribute overwrite causes transaction overrun
fs/xfs/xfs_attr.c| 24 +++-
fs/xfs/xfs_attr_leaf.c | 21
On Thu, May 08, 2014 at 04:13:00PM -0700, Linus Torvalds wrote:
On Thu, May 8, 2014 at 2:12 PM, Dave Chinner da...@fromorbit.com wrote:
BTW, will GPG signing these pull requests cause you problems?
Nope. But I won't be checking email signatures. GPG email signing is
so badly done
xfs: simplify attr name setup
xfs: pass struct da_args to xfs_attr_calc_size
xfs: tone down writepage/releasepage WARN_ONs
Dan Carpenter (1):
xfs: small cleanup in xfs_lowbit64()
Dave Chinner (50):
xfs: remove dquot hints
xfs: truncate_setsize should be outside
), so this is one for the mm
folk to work out...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
On Mon, May 19, 2014 at 11:43:13AM +0200, Jan Kara wrote:
On Fri 16-05-14 10:11:56, Dave Chinner wrote:
On Fri, May 16, 2014 at 01:19:09AM +0200, Mateusz Guzik wrote:
On Fri, May 16, 2014 at 08:51:41AM +1000, Dave Chinner wrote:
On Fri, May 16, 2014 at 12:34:40AM +0200, Mateusz Guzik
does this.
Tetsuo-san, when it comes to problems involving XFS, you should
really CC x...@oss.sgi.com because very few people really know how
XFS works and even fewer still know how it is supposed to interact
with memory reclaim
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
xfs: block
On Mon, May 19, 2014 at 05:55:30PM -0700, Daniel Phillips wrote:
On 05/18/2014 04:55 PM, Dave Chinner wrote:
On Fri, May 16, 2014 at 05:50:59PM -0700, Daniel Phillips wrote:
static const struct inode_operations tux_file_iops = {
// .permission = ext4_permission,
.setattr
On Tue, May 20, 2014 at 12:54:29PM +0900, Tetsuo Handa wrote:
Dave Chinner wrote:
So, XFS should be passing kswapd context to the workqueue allocation
context. The patch below does this.
Tetsuo-san, when it comes to problems involving XFS, you should
really CC x...@oss.sgi.com because
On Mon, May 19, 2014 at 10:59:15PM -0700, Andrew Morton wrote:
On Tue, 20 May 2014 10:44:49 +1000 Dave Chinner da...@fromorbit.com wrote:
@@ -258,14 +258,23 @@ xfs_bmapi_allocate_worker(
struct xfs_bmalloca *args = container_of(work
On Mon, May 19, 2014 at 11:03:11PM -0700, Andrew Morton wrote:
On Mon, 19 May 2014 22:59:15 -0700 Andrew Morton a...@linux-foundation.org
wrote:
On Tue, 20 May 2014 10:44:49 +1000 Dave Chinner da...@fromorbit.com wrote:
@@ -258,14 +258,23 @@ xfs_bmapi_allocate_worker(
struct
On Tue, Apr 29, 2014 at 01:57:14AM +0200, Andres Freund wrote:
Hi Dave,
On 2014-04-29 09:47:56 +1000, Dave Chinner wrote:
ping?
I'd replied at http://marc.info/?l=linux-mmm=139730910307321w=2
I missed it, sorry.
I've had a bit more time to look at this behaviour now and tweaked
On Wed, May 14, 2014 at 10:17:49PM -0400, Theodore Ts'o wrote:
On Thu, May 15, 2014 at 07:54:57AM +1000, Dave Chinner wrote:
On Tue, May 13, 2014 at 08:31:02PM +0200, Mateusz Guzik wrote:
This helps hang troubleshooting efforts when only dmesg is available.
I really don't think
On Thu, May 15, 2014 at 12:13:56PM +0200, Jan Kara wrote:
On Thu 15-05-14 08:37:45, Dave Chinner wrote:
On Thu, May 15, 2014 at 08:00:52AM +1000, Dave Chinner wrote:
On Wed, May 14, 2014 at 01:39:45PM +0200, Jan Kara wrote:
On Wed 14-05-14 13:26:21, Mateusz Guzik wrote:
On Wed, May
To: Dave Chinner da...@fromorbit.com, Jan Kara j...@suse.cz
Cc: Mateusz Guzik mgu...@redhat.com, linux-kernel@vger.kernel.org,
linux-fsde...@vger.kernel.org, Josef Bacik jba...@fb.com,
Al Viro v...@zeniv.linux.org.uk, Joe Perches j...@perches.com
Subject: Re: [PATCH V2 2/2] fs: print
On Fri, May 16, 2014 at 12:34:40AM +0200, Mateusz Guzik wrote:
On Fri, May 16, 2014 at 08:21:35AM +1000, Dave Chinner wrote:
IOW, a new column in mountinfo. For frozen filesystems it would contain
'frozen_by=[%s]:[%d]' (escaped comm, pid).
I really don't see that the process that froze
On Fri, May 16, 2014 at 01:19:09AM +0200, Mateusz Guzik wrote:
On Fri, May 16, 2014 at 08:51:41AM +1000, Dave Chinner wrote:
On Fri, May 16, 2014 at 12:34:40AM +0200, Mateusz Guzik wrote:
On Fri, May 16, 2014 at 08:21:35AM +1000, Dave Chinner wrote:
IOW, a new column in mountinfo
.
Dave Chinner (9):
xfs: xfs_dir_fsync() returns positive errno
xfs: fix incorrect error sign in xfs_file_aio_read
xfs: xfs_commit_metadata returns wrong errno
xfs: correct error sign on COLLAPSE_RANGE errors
xfs: fix wrong
,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, May 28, 2014 at 12:06:58PM -0400, Johannes Weiner wrote:
On Wed, May 28, 2014 at 07:13:45PM +1000, Dave Chinner wrote:
On Wed, May 28, 2014 at 06:37:38PM +1000, Dave Chinner wrote:
[ cc XFS list ]
[and now there is a complete copy on the XFs list, I'll add my 2c]
On Wed
problems.
Even when the reported problem is from IO to an ext4 filesystem.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
is not worst case stack usage here
and disabling it won't prevent this stack overflow from happening.
Direct reclaim will simply throttle elsewhere and that will still
cause the plug to be flushed, the IO to be issued and the stack to
overflow.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Wed, May 28, 2014 at 03:42:18PM -0700, H. Peter Anvin wrote:
On 05/28/2014 03:11 PM, Dave Chinner wrote:
On Wed, May 28, 2014 at 07:23:23AM -0700, H. Peter Anvin wrote:
We tried for 4K on x86-64, too, for b quite a while as I recall.
The kernel stack is a one of the main costs
On Wed, May 28, 2014 at 03:41:11PM -0700, Linus Torvalds wrote:
On Wed, May 28, 2014 at 3:31 PM, Dave Chinner da...@fromorbit.com wrote:
Indeed, the call chain reported here is not caused by swap issuing
IO.
Well, that's one way of reading that callchain.
I think it's the *wrong* way
On Thu, May 29, 2014 at 11:30:07AM +1000, Dave Chinner wrote:
On Wed, May 28, 2014 at 03:41:11PM -0700, Linus Torvalds wrote:
commit a237c1c5bc5dc5c76a21be922dca4826f3eca8ca
Author: Jens Axboe jax...@fusionio.com
Date: Sat Apr 16 13:27:55 2011 +0200
block: let io_schedule() flush
On Wed, May 28, 2014 at 07:42:40PM -0700, Linus Torvalds wrote:
On Wed, May 28, 2014 at 6:30 PM, Dave Chinner da...@fromorbit.com wrote:
You're focussing on the specific symptoms, not the bigger picture.
i.e. you're ignoring all the other let's start IO triggers in
direct reclaim. e.g
On Thu, May 29, 2014 at 11:34:21AM +0800, Gu Zheng wrote:
Hi Dave,
On 05/28/2014 02:00 PM, Dave Chinner wrote:
On Wed, May 28, 2014 at 01:19:16PM +0800, Gu Zheng wrote:
Hi all,
When running the latest Linus' tree, the following possible deadlock
warning occurs.
false positive
);
+ blk_schedule_flush_plug(current);
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
it might be an idea to push
this toward inclusion in xfstests? We have filesystem specific test
sections that would suit this, and the test structure is actually
not all that different to what xfstests uses...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list
On Thu, May 29, 2014 at 08:24:49AM -0700, Linus Torvalds wrote:
On Thu, May 29, 2014 at 12:26 AM, Dave Chinner da...@fromorbit.com wrote:
What concerns me about both __alloc_pages_nodemask() and
kernel_map_pages is that when I look at the code I see functions
that have no obvious stack
On Fri, May 30, 2014 at 08:36:38AM +0900, Minchan Kim wrote:
Hello Dave,
On Thu, May 29, 2014 at 11:58:30AM +1000, Dave Chinner wrote:
On Thu, May 29, 2014 at 11:30:07AM +1000, Dave Chinner wrote:
On Wed, May 28, 2014 at 03:41:11PM -0700, Linus Torvalds wrote:
commit
On Thu, May 29, 2014 at 08:06:49PM -0400, Dave Jones wrote:
On Fri, May 30, 2014 at 09:53:08AM +1000, Dave Chinner wrote:
That sounds like a plan. Perhaps it would be useful to add a
WARN_ON_ONCE(stack_usage 8k) (or some other arbitrary depth beyond
8k) so that we get some indication
On Fri, May 30, 2014 at 09:32:19AM +0900, Minchan Kim wrote:
On Fri, May 30, 2014 at 10:21:13AM +1000, Dave Chinner wrote:
On Thu, May 29, 2014 at 08:06:49PM -0400, Dave Jones wrote:
On Fri, May 30, 2014 at 09:53:08AM +1000, Dave Chinner wrote:
That sounds like a plan. Perhaps
,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to lifting the VFS limit by using
struct inode_time in XFS.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Dave Chinner da...@fromorbit.com
Cc: x...@oss.sgi.com
---
fs/xfs/time.h| 4 ++--
fs/xfs/xfs_inode.c | 2 +-
fs/xfs/xfs_iops.c| 2 +-
fs/xfs/xfs_trans_inode.c
On Fri, May 30, 2014 at 05:41:14PM -0700, H. Peter Anvin wrote:
On 05/30/2014 05:37 PM, Dave Chinner wrote:
IOWs, the filesystem has to be able to reject any attempt to set a
timestamp that is can't represent on disk otherwise Bad Stuff will
happen,
Actually it is questionable
[ Please don't top post. ]
On Fri, May 30, 2014 at 06:22:55PM -0700, H. Peter Anvin wrote:
On May 30, 2014 6:14:50 PM PDT, Dave Chinner da...@fromorbit.com wrote:
On Fri, May 30, 2014 at 05:41:14PM -0700, H. Peter Anvin wrote:
On 05/30/2014 05:37 PM, Dave Chinner wrote:
IOWs
On Sat, May 31, 2014 at 05:37:52PM +0200, Arnd Bergmann wrote:
On Saturday 31 May 2014 11:14:50 Dave Chinner wrote:
On Fri, May 30, 2014 at 05:41:14PM -0700, H. Peter Anvin wrote:
On 05/30/2014 05:37 PM, Dave Chinner wrote:
IOWs, the filesystem has to be able to reject any attempt
On Sat, May 31, 2014 at 01:41:56AM -0700, H. Peter Anvin wrote:
On 05/30/2014 10:54 PM, Dave Chinner wrote:
If we are changing the in-kernel timestamp to have a greater dynamic
range that anything we current support on disk, then we need support
for all filesystems for similar
On Sun, Jun 01, 2014 at 10:24:37AM +1000, Dave Chinner wrote:
On Sat, May 31, 2014 at 05:37:52PM +0200, Arnd Bergmann wrote:
In my list at http://kernelnewbies.org/y2038, I found that almost
all file systems at least times until 2106, because they treat
the on-disk value as unsigned on 64
(E2BIG, I
think) if you try. XFS, OTOH, handles this just fine and so it
continues to work. It's exactly the same with timestamps - there's a
physical limit to what can sanely be stored in any given filesystem
and it's an *error condition* to go beyond that limit
Cheers,
Dave.
--
Dave Chinner
.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
i_lock. I'd suggest you want to
separate the use of the vfs inode ilock from the locking heirarchy
of the tux3 inode
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
not an invalid superblock (EINVAL)
nor is it a corrupted superblock (EFSCORRUPTED), so it's something
else...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
On Mon, May 26, 2014 at 10:08:13AM +1000, Dave Chinner wrote:
On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote:
On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov plamen.s...@gmail.com
wrote:
The story short: on systems with btrfs root I have a kernel .config with
ext4
in behavior.
Yup, it's buggy, though not in an obvious way. I'll have a patch for
it soon.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Mon, May 26, 2014 at 11:19:04AM +1000, Dave Chinner wrote:
On Mon, May 26, 2014 at 10:08:13AM +1000, Dave Chinner wrote:
On Sun, May 25, 2014 at 01:04:09PM -0700, Linus Torvalds wrote:
On Mon, May 5, 2014 at 11:34 AM, Plamen Petrov plamen.s...@gmail.com
wrote:
The story short
to the cgroup LRU list. IOWs mem_cgroups are your
problem, not XFS or NFS.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
will
adversely impact the balance of the system under memory intensive
filesystem workloads. In these worklaods, almost all allocations are
done in the GFP_NOFS or GFP_NOIO contexts so not deferring the work
will will effectively stop superblock cache reclaim entirely
Cheers,
Dave.
--
Dave Chinner
On Tue, May 27, 2014 at 04:19:12PM -0700, Hugh Dickins wrote:
On Wed, 28 May 2014, Konstantin Khlebnikov wrote:
On Wed, May 28, 2014 at 1:17 AM, Hugh Dickins hu...@google.com wrote:
On Tue, 27 May 2014, Dave Chinner wrote:
On Mon, May 26, 2014 at 02:44:29PM -0700, Hugh Dickins wrote
inodes, nor on their security contexts. Nor can you
take a page fault on a directory inode, which is the XFS inode lock
class it's complaining about.
Fundamentally, the problem here is shmem instantiating a new inode
with the mmap_sem held. That's just plain wrong...
Cheers,
Dave.
--
Dave
/include/asm/page_64_types.h
@@ -1,7 +1,7 @@
#ifndef _ASM_X86_PAGE_64_DEFS_H
#define _ASM_X86_PAGE_64_DEFS_H
-#define THREAD_SIZE_ORDER1
+#define THREAD_SIZE_ORDER2
#define THREAD_SIZE (PAGE_SIZE THREAD_SIZE_ORDER)
#define CURRENT_MASK (~(THREAD_SIZE - 1))
--
Dave Chinner
On Wed, May 28, 2014 at 06:37:38PM +1000, Dave Chinner wrote:
[ cc XFS list ]
[and now there is a complete copy on the XFs list, I'll add my 2c]
On Wed, May 28, 2014 at 03:53:59PM +0900, Minchan Kim wrote:
While I play inhouse patches with much memory pressure on qemu-kvm,
3.14 kernel
, non-invasive ro state...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
the same way so that it is silent when it just works, and the state
can easily be determined when something goes wrong.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
dmesg output for something that already has a working error
reporting path?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Thu, May 15, 2014 at 08:00:52AM +1000, Dave Chinner wrote:
On Wed, May 14, 2014 at 01:39:45PM +0200, Jan Kara wrote:
On Wed 14-05-14 13:26:21, Mateusz Guzik wrote:
On Wed, May 14, 2014 at 01:14:49PM +0200, Jan Kara wrote:
On Wed 14-05-14 00:04:43, Mateusz Guzik wrote:
This helps
the
block layer stack usage...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
the tag - they should be using Acked-by: if
all they have done is read the code in their mail program
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
On Mon, Jun 02, 2014 at 01:43:44PM +0200, Arnd Bergmann wrote:
On Monday 02 June 2014 10:28:22 Dave Chinner wrote:
On Sun, Jun 01, 2014 at 10:24:37AM +1000, Dave Chinner wrote:
On Sat, May 31, 2014 at 05:37:52PM +0200, Arnd Bergmann wrote:
In my list at http://kernelnewbies.org/y2038, I
On Mon, Jun 02, 2014 at 04:59:15PM -0700, j...@joshtriplett.org wrote:
On Tue, Jun 03, 2014 at 09:19:49AM +1000, Dave Chinner wrote:
On Mon, Jun 02, 2014 at 12:17:46PM -0700, Joe Perches wrote:
What it needs is testing, not reviewing.
I tested it for all of 10 seconds.
From
[ please line wrap at something sane like 68 columns ]
On Mon, Jun 02, 2014 at 01:02:29PM -0700, Daniel Phillips wrote:
On 06/01/2014 08:15 PM, Dave Chinner wrote:
On Sun, Jun 01, 2014 at 02:41:02PM -0700, I wrote:
+
+/*
+ * Add inode to writeback dirty list with current time
On Mon, Jun 02, 2014 at 10:30:07AM +0200, Christian Stroetmann wrote:
When I followed the advice of Dave Chinner:
We're not going to merge that page forking stuff (like you were
told at LSF 2013 more than a year ago:
http://lwn.net/Articles/548091/) without rigorous design review
On Mon, Jun 02, 2014 at 09:30:45PM -0400, Steven Rostedt wrote:
On Tue, 3 Jun 2014 11:11:25 +1000
Dave Chinner da...@fromorbit.com wrote:
You've ignored the (c).(2) free of known issues criteria there.
You cannot say a patch is free of issues if you haven't applied,
compiled and tested
On Tue, Jun 03, 2014 at 12:01:11AM -0700, Daniel Phillips wrote:
Hi Dave,
On 06/02/2014 08:33 PM, Dave Chinner wrote:
On Mon, Jun 02, 2014 at 01:02:29PM -0700, Daniel Phillips wrote:
H - this is using the wb dirty lists and locks, but you
don't pass the wb structure to the writeback
On Tue, Jun 03, 2014 at 04:47:52PM +0900, OGAWA Hirofumi wrote:
Daniel Phillips dan...@phunq.net writes:
Hi Dave,
On 06/02/2014 08:33 PM, Dave Chinner wrote:
On Mon, Jun 02, 2014 at 01:02:29PM -0700, Daniel Phillips wrote:
Redirty_tail nearly works, but if (!list_empty(wb-b_dirty
On Tue, Jun 03, 2014 at 09:33:36AM +0200, Arnd Bergmann wrote:
On Tuesday 03 June 2014 10:32:27 Dave Chinner wrote:
On Mon, Jun 02, 2014 at 01:43:44PM +0200, Arnd Bergmann wrote:
On Monday 02 June 2014 10:28:22 Dave Chinner wrote:
On Sun, Jun 01, 2014 at 10:24:37AM +1000, Dave Chinner
to be independent of the physical filesystem time encoding
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
On Tue, Jun 03, 2014 at 01:43:47PM -0400, Steven Rostedt wrote:
On Tue, 3 Jun 2014 17:16:54 +1000
Dave Chinner da...@fromorbit.com wrote:
If you take it to an extremes. Think about what you can test in 15
minutes. Or for larger patchsets, how long it takes you to read the
patchset
501 - 600 of 3916 matches
Mail list logo
