On Monday 05 January 2009 05:41:03 Matthew Wilcox wrote:
On Sun, Jan 04, 2009 at 07:21:50PM +0100, Peter Zijlstra wrote:
The -rt tree has adaptive spin patches for the rtmutex code, its really
not all that hard to do -- the rtmutex code is way more tricky than the
regular mutexes due to all
[trim ccs]
Feel free to ignore this diversion ;) I'd like to see btrfs go upstream
sooner rather than later. But eventually we'll have to resurrect fsblock
vs extent map discussion.
On Tuesday 06 January 2009 00:21:43 Chris Mason wrote:
On Mon, 2009-01-05 at 21:32 +1100, Nick Piggin wrote
On Wed, Jan 14, 2009 at 06:22:36PM +0100, Peter Zijlstra wrote:
On Wed, 2009-01-14 at 18:18 +0100, Nick Piggin wrote:
@@ -173,21 +237,21 @@ __mutex_lock_common(struct mutex *lock,
spin_unlock_mutex(lock-wait_lock, flags
On Wed, Jan 14, 2009 at 07:23:12PM +0200, Avi Kivity wrote:
Nick Piggin wrote:
(no they're not, Nick's ticket locks still spin on a shared cacheline
IIRC -- the MCS locks mentioned could fix this)
It reminds me. I wrote a basic variation of MCS spinlocks a while back. And
converted
On Wed, Jan 14, 2009 at 01:35:29PM -0800, Andrew Morton wrote:
You're taking a whizzy new feature which drastically changes a critical
core kernel feature and jamming it into mainline with a vestigial
amount of testing coverage without giving sufficient care and thought
to the practical
On Thu, Jan 15, 2009 at 08:44:03AM +0100, Peter Zijlstra wrote:
On Thu, 2009-01-15 at 01:46 +0100, Nick Piggin wrote:
Hmm, well this is rather a slow path, I would say. I'd prefer not to
modify schedule in this way (if we just get scheduled back on after
being switched away
On Thu, Jan 15, 2009 at 10:16:53AM -0800, Linus Torvalds wrote:
On Thu, 15 Jan 2009, Ingo Molnar wrote:
btw., i think spin-mutexes have a design advantage here: in a lot of code
areas it's quite difficult to use spinlocks - cannot allocate memory,
cannot call any code that can
On Tue, Jan 20, 2009 at 08:01:52AM +1100, Linus Torvalds wrote:
On Mon, 19 Jan 2009, Nick Piggin wrote:
I want to know what is the problem with the restrict keyword?
I'm sure I've read Linus ranting about how bad it is in the
past...
No, I don't think I've ranted about 'restrict
On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell it that multiple given
arrays are independent and then give the loop optimizer
more freedom to handle expressions in the loop that
accesses
On Wed, Jan 21, 2009 at 10:20:49AM +0100, Andi Kleen wrote:
On Wed, Jan 21, 2009 at 09:52:08AM +0100, Nick Piggin wrote:
On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell
working again.
Signed-off-by: Nick Piggin npig...@suse.de
---
fs/btrfs/inode.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
Index: linux-2.6/fs/btrfs/inode.c
===
--- linux-2.6.orig/fs/btrfs/inode.c
Hi Chris,
Don't know if this is a known issue, but I have btrfs (after my previous
inode_tree fixup patch) failing fsx-linux in Linus's current git tree.
This makes it a bit hard for me to test my btrfs truncate conversion patch
unfortunately, though it does seem pretty stable so I will probably
On Wed, Aug 19, 2009 at 02:56:54AM +0800, Yan, Zheng wrote:
2009/8/19 Nick Piggin npig...@suse.de:
Hi,
Ran into a problem stress testing my btrfs truncate conversion attempt...
Unfortunately it was an existing btrfs problem. Fortunately I think I
was able to fix it.
Thanks,
Nick
On Tue, Aug 18, 2009 at 11:19:10PM +0200, Jens Axboe wrote:
On Wed, Aug 19 2009, Yan, Zheng wrote:
2009/8/19 Nick Piggin npig...@suse.de:
Hi,
Ran into a problem stress testing my btrfs truncate conversion attempt...
Unfortunately it was an existing btrfs problem. Fortunately I
On Tue, Aug 18, 2009 at 01:59:50PM -0400, Josef Bacik wrote:
On Tue, Aug 18, 2009 at 07:26:41PM +0200, Nick Piggin wrote:
Hi Chris,
Don't know if this is a known issue, but I have btrfs (after my previous
inode_tree fixup patch) failing fsx-linux in Linus's current git tree
On Wed, Aug 19, 2009 at 10:46:59AM +0200, Jens Axboe wrote:
On Wed, Aug 19 2009, Nick Piggin wrote:
See my other reply. It *can* work with key aliases, but this particular
code does not.
It is pretty easy obviously to put in duplicates because the rbtree
code doesn't know about keys
On Wed, Aug 19, 2009 at 05:34:08PM +0800, Yan, Zheng wrote:
2009/8/19 Nick Piggin npig...@suse.de:
On Wed, Aug 19, 2009 at 04:56:12PM +0800, Yan, Zheng wrote:
Firstly, the insert/delete code is wrong for duplicates and it will crash in
the absense of any search activity. Agree?
Secondly
On Tue, Aug 18, 2009 at 01:59:50PM -0400, Josef Bacik wrote:
On Tue, Aug 18, 2009 at 07:26:41PM +0200, Nick Piggin wrote:
Hi Chris,
Don't know if this is a known issue, but I have btrfs (after my previous
inode_tree fixup patch) failing fsx-linux in Linus's current git tree
On Wed, Sep 02, 2009 at 03:07:21PM -0400, Chris Mason wrote:
On Wed, Sep 02, 2009 at 07:14:50PM +0200, Nick Piggin wrote:
On Tue, Aug 18, 2009 at 01:59:50PM -0400, Josef Bacik wrote:
I'll take a look at this later today and see what I can come up with.
Thanks
for reporting
On Wed, Sep 09, 2009 at 09:13:49AM -0400, Chris Mason wrote:
On Tue, Aug 18, 2009 at 07:26:41PM +0200, Nick Piggin wrote:
Hi Chris,
Don't know if this is a known issue, but I have btrfs (after my previous
inode_tree fixup patch) failing fsx-linux in Linus's current git tree
On Wed, Sep 09, 2009 at 09:37:29AM -0400, Chris Mason wrote:
On Wed, Sep 09, 2009 at 03:34:35PM +0200, Nick Piggin wrote:
Which cases do set_page_dirty happen without page_mkwrite? For fsx-linux
I hope there shouldn't be any...
I've been assuming its the zap_pte_range part, but now I have
On Tue, Nov 30, 2010 at 11:01:18AM +1100, Nick Piggin wrote:
On Mon, Nov 29, 2010 at 02:26:03PM -0800, Andrew Morton wrote:
On Thu, 25 Nov 2010 14:53:56 +1100
Nick Piggin npig...@kernel.dk wrote:
On Wed, Nov 24, 2010 at 02:10:28PM +0100, Jan Kara wrote:
Well, for now, the easiest
Signed-off-by: Nick Piggin npig...@suse.de
--
Index: linux-2.6/fs/btrfs/compression.c
===
--- linux-2.6.orig/fs/btrfs/compression.c
+++ linux-2.6/fs/btrfs/compression.c
@@ -478,7 +478,7 @@ static noinline int add_ra_bio_pages(str
, percpu
lru ordering is preserved, and finally don't need to flush pagevec
before returning so batching may be shared with other LRU insertions.
Signed-off-by: Nick Piggin npig...@suse.de:
---
fs/btrfs/compression.c | 20 ++--
fs/btrfs/extent_io.c | 22 +-
2
On Wed, Mar 17, 2010 at 05:20:53PM +1100, Nick Piggin wrote:
btrfs: use add_to_page_cache_lru, use __page_cache_alloc
Pagecache pages should be allocated with __page_cache_alloc, so they
obey pagecache memory policies.
add_to_page_cache_lru is exported, so it should be used. Benefits over
I saw a lock order warning on ext4 trigger. This should solve it.
Raciness shouldn't matter much, because writeback can stop just
after we make the test and return anyway (so the API is racy anyway).
Signed-off-by: Nick Piggin npig...@kernel.dk
Index: linux-2.6/fs/fs-writeback.c
On Tue, Nov 16, 2010 at 12:32:52PM -0800, Andrew Morton wrote:
On Tue, 16 Nov 2010 22:00:58 +1100
Nick Piggin npig...@kernel.dk wrote:
I saw a lock order warning on ext4 trigger. This should solve it.
Send us the trace, please.
I lost it, sorry.
The code comment implies that someone
On Tue, Nov 16, 2010 at 10:30:37PM -0600, Eric Sandeen wrote:
On 11/16/10 7:01 AM, Jan Kara wrote:
On Tue 16-11-10 22:00:58, Nick Piggin wrote:
I saw a lock order warning on ext4 trigger. This should solve it.
Raciness shouldn't matter much, because writeback can stop just
after we make
On Tue, Nov 16, 2010 at 11:05:52PM -0600, Eric Sandeen wrote:
On 11/16/10 10:38 PM, Nick Piggin wrote:
as for the locking problems ... sorry about that!
That's no problem. So is that an ack? :)
I'd like to test it with the original case it was supposed to solve; will
do
On Wed, Nov 17, 2010 at 07:29:00PM -0800, Andrew Morton wrote:
On Wed, 17 Nov 2010 22:06:13 -0500 Ted Ts'o ty...@mit.edu wrote:
On Wed, Nov 17, 2010 at 05:10:57PM +1100, Nick Piggin wrote:
On Tue, Nov 16, 2010 at 11:05:52PM -0600, Eric Sandeen wrote:
On 11/16/10 10:38 PM, Nick Piggin
On Wed, Nov 17, 2010 at 10:28:34PM -0800, Andrew Morton wrote:
On Thu, 18 Nov 2010 17:00:00 +1100 Nick Piggin npig...@kernel.dk wrote:
On Wed, Nov 17, 2010 at 07:29:00PM -0800, Andrew Morton wrote:
On Wed, 17 Nov 2010 22:06:13 -0500 Ted Ts'o ty...@mit.edu wrote:
On Wed, Nov 17
On Thu, Nov 18, 2010 at 09:58:31AM -0800, Andrew Morton wrote:
On Thu, 18 Nov 2010 19:18:22 +1100 Nick Piggin npig...@kernel.dk wrote:
On Wed, Nov 17, 2010 at 10:28:34PM -0800, Andrew Morton wrote:
Logically I'd expect i_mutex to nest inside s_umount. Because s_umount
is a per
On Fri, Nov 19, 2010 at 01:45:52AM +0100, Jan Kara wrote:
On Wed 17-11-10 22:28:34, Andrew Morton wrote:
The fact that a call to -write_begin can randomly return with s_umount
held, to be randomly released at some random time in the future is a
bit ugly, isn't it? write_begin is a pretty
On Mon, Nov 22, 2010 at 07:16:55PM +0100, Jan Kara wrote:
On Fri 19-11-10 16:16:19, Nick Piggin wrote:
On Fri, Nov 19, 2010 at 01:45:52AM +0100, Jan Kara wrote:
On Wed 17-11-10 22:28:34, Andrew Morton wrote:
The fact that a call to -write_begin can randomly return with s_umount
held
more.
ext4 now passes extensive stress testing with xfstests, fs_mark, dbench,
with a writeback_inodes_if_idle call added directly into ext4_da_write_begin
to trigger the path frequently. Previously it would spew lockdep stuff and
hang in a number of ways very quickly.
Signed-off-by: Nick Piggin
On Tue, Nov 23, 2010 at 09:02:39PM +1100, Nick Piggin wrote:
int writeback_inodes_sb_if_idle(struct super_block *sb)
{
if (!writeback_in_progress(sb-s_bdi)) {
- down_read(sb-s_umount);
- writeback_inodes_sb(sb);
- up_read(sb-s_umount
On Tue, Nov 23, 2010 at 12:26:31PM +0200, Boaz Harrosh wrote:
*
* Invoke writeback_inodes_sb if no writeback is currently underway.
* Returns 1 if writeback was started, 0 if not.
+ *
+ * Even if 1 is returned, writeback may not be started if memory allocation
+ * fails. This
very quickly.
Signed-off-by: Nick Piggin npig...@kernel.dk
---
fs/fs-writeback.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
Index: linux-2.6/fs/fs-writeback.c
,
with a writeback_inodes_if_idle call added directly into
ext4_da_write_begin
to trigger the path frequently. Previously it would spew lockdep stuff
and
hang in a number of ways very quickly.
Signed-off-by: Nick Piggin npig...@kernel.dk
---
fs/fs-writeback.c | 32
On Tue, Nov 23, 2010 at 02:18:57PM +0100, Jan Kara wrote:
On Tue 23-11-10 21:11:49, Nick Piggin wrote:
The issue of writeback_inodes_sb being synchronous so far as it has to
wait until the work has been dequeued is another subtlety. That is a
funny interface though, really. It has 3 callers
On Mon, Nov 29, 2010 at 02:26:03PM -0800, Andrew Morton wrote:
On Thu, 25 Nov 2010 14:53:56 +1100
Nick Piggin npig...@kernel.dk wrote:
On Wed, Nov 24, 2010 at 02:10:28PM +0100, Jan Kara wrote:
Well, for now, the easiest and simplest fix is my patch, I think. The
objection is that we
41 matches
Mail list logo
