Hello,
I'm having a problem on the newest version of linus's git tree with my qla2xxx
card. This is on a UP box, the problem doesn't happen on my similarly
configured SMP box. When I unload and then try to load the qla2xxx driver again
I get this message
kobject_add failed for 3:0:0:0 with
Hello,
Resending this to a wider audience (thanks Andrew). I'm having a problem on
the newest version of linus's git tree with my qla2xxx card. This is on a UP
box, the problem doesn't happen on my similarly configured SMP box. When I
unload and then try to load the qla2xxx driver again I
On Thu, Apr 19, 2007 at 10:02:36AM -0400, James Bottomley wrote:
On Thu, 2007-04-19 at 09:25 -0400, Josef Bacik wrote:
Looking through everything I came to the conclusion that we don't really
need
the scsi_sysfs_add_devices in scsi_finish_async_scan, which gets run
everytime
we do
On Sat, Apr 21, 2007 at 12:23:45AM -0700, Andrew Morton wrote:
On Thu, 19 Apr 2007 11:06:56 -0400 Josef Bacik [EMAIL PROTECTED] wrote:
On Thu, Apr 19, 2007 at 10:02:36AM -0400, James Bottomley wrote:
On Thu, 2007-04-19 at 09:25 -0400, Josef Bacik wrote:
Looking through everything I
On Sat, Apr 21, 2007 at 09:59:56AM -0400, Josef Bacik wrote:
On Sat, Apr 21, 2007 at 12:23:45AM -0700, Andrew Morton wrote:
On Thu, 19 Apr 2007 11:06:56 -0400 Josef Bacik [EMAIL PROTECTED] wrote:
On Thu, Apr 19, 2007 at 10:02:36AM -0400, James Bottomley wrote:
On Thu, 2007-04-19 at 09
On Tue, Aug 21, 2007 at 01:45:02PM -0400, Josef Bacik wrote:
handle_t's are removed and such before processing the revoke lists, but
right
before we process the revoke lists we set the journals running
transaction to
NULL, which means we can continue on our merry way. AFAICS
(at least I think so :)
fix. Thank you,
Signed-off-by: Josef Bacik [EMAIL PROTECTED]
diff --git a/fs/jbd/revoke.c b/fs/jbd/revoke.c
index 62e13c8..317f598 100644
--- a/fs/jbd/revoke.c
+++ b/fs/jbd/revoke.c
@@ -518,6 +518,7 @@ void journal_write_revoke_records(journal_t *journal,
for (i = 0; i
On Thu, Aug 16, 2007 at 06:08:35PM +0200, Jan Kara wrote:
Hello,
It is possible to panic the box by a race condition that exists in the
journalling code where we do not take the j_revoke_lock when traversing
the
journal's revoked record list. This patch has been tested and
On Mon, Aug 20, 2007 at 05:20:21PM +0200, Jan Kara wrote:
OK, thanks. So record probably points to an already freed memory which has
been overwritten by garbage...
Thanks for details. I'm still not convinced. What they essentially
write is that slab cache revoke_record_cache is not
On Tue, Aug 21, 2007 at 06:48:15PM +0200, Jan Kara wrote:
On Tue 21-08-07 11:43:12, Josef Bacik wrote:
On Mon, Aug 20, 2007 at 05:20:21PM +0200, Jan Kara wrote:
OK, thanks. So record probably points to an already freed memory which
has
been overwritten by garbage
On Tue, Feb 26, 2013 at 10:22:47PM -0700, Dave Jones wrote:
Something I've yet to repeat managed to leak a whole bunch of memory
while I was travelling, and locked up my workstation.
When I got home, this was the last thing printed out before it locked up
(it did make it into the logs
On Wed, Feb 27, 2013 at 07:31:11AM -0700, Ahmet Inan wrote:
Yeah we have a lot of
ptr = kmalloc();
BUG_ON(ptr);
everywhere. I'll fix this one up but I really need to sit down and go
through
all of them and make sure we do the right thing in all these places.
Thanks,
But
On Wed, Feb 27, 2013 at 3:10 PM, Ahmet Inan
ai...@mathematik.uni-freiburg.de wrote:
On Wed, Feb 27, 2013 at 7:26 PM, Josef Bacik jba...@fusionio.com wrote:
On Wed, Feb 27, 2013 at 07:31:11AM -0700, Ahmet Inan wrote:
Yeah we have a lot of
ptr = kmalloc();
BUG_ON(ptr);
everywhere
On Sat, Jan 19, 2013 at 08:27:45AM -0700, Cong Ding wrote:
The bug happens when rb_node == NULL. It causes variable node to be NULL and
then the NULL pointer is dereferenced this line:
BUG_ON((struct btrfs_root *)node-data != root);
Based on my analysis, function tree_search should not
On Mon, Sep 10, 2012 at 12:38:35AM -0600, Wang Sheng-Hui wrote:
To check the duplicated super blocks, use BTRFS_SUPER_MIRROR_MAX
as the loops limit.
Signed-off-by: Wang Sheng-Hui shh...@gmail.com
---
fs/btrfs/disk-io.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
On Tuesday 05 February 2008 12:27:31 pm Jan Kara wrote:
Hello,
Sorry for replying a bit late but I'm currently falling behind in
maling-list reading...
The way jbd tries to determine if there is enough space left on the
journal in order to start a new transaction is looking at the
the assertion, I could very easily reproduce the situation where
t_outstanding_credits was than t_nr_buffers.
Signed-off-by: Josef Bacik [EMAIL PROTECTED]
diff --git a/fs/jbd/commit.c b/fs/jbd/commit.c
index 31853eb..e385a5c 100644
--- a/fs/jbd/commit.c
+++ b/fs/jbd/commit.c
@@ -561,13 +561,6 @@ void
On Thu, Jan 31, 2008 at 12:35:43PM -0700, Andreas Dilger wrote:
On Jan 31, 2008 11:14 -0500, Josef Bacik wrote:
[snip excellent analysis]
So you get into this situation where
t_nr_buffers (the actual number of buffers that are on the transaction) is
greater than the number of buffers
On Tue, Jul 30, 2013 at 11:07:30AM +0200, Geert Uytterhoeven wrote:
On Tue, 30 Jul 2013, Thorsten Glaser wrote:
NEW problem: btrfs doesn’t work at all. I had to reboot my
buildd into 3.2 using echo s/u/s/o /proc/sysrq-trigger as
the attempt to mount it left the system hanging there.
[
On Tue, Jul 30, 2013 at 07:02:29PM +, Thorsten Glaser wrote:
Josef Bacik dixit:
Can you gdb btrfs.ko and do
list *(__btrfs_map_block+0x11c)
Not easily (the kernel image is from a .deb package),
and even in a compile tree gdb just says:
No symbol table is loaded. Use the file
On Mon, Nov 04, 2013 at 03:36:24PM -0800, Kent Overstreet wrote:
We get a measurable performance increase by handling this in the driver when
we're already looping over the biovec, instead of handling it separately in
generic_make_request() (or bio_add_page() originally)
Signed-off-by: Kent
with multipage bvecs later.
The btrfs parts of this look good to me, you can add
Reviewed-by: Josef Bacik jba...@fusionio.com
Thanks for this,
Josef
--
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
On Mon, Sep 16, 2013 at 04:05:47PM -0700, Andrew Morton wrote:
On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik jba...@fusionio.com wrote:
Btrfs uses an rwsem to control access to its extent tree. Threads will
hold a
read lock on this rwsem while they scan the extent tree
On Mon, Sep 16, 2013 at 06:08:42PM -0700, David Daney wrote:
On 09/16/2013 05:37 PM, Peter Hurley wrote:
On 09/16/2013 08:29 PM, David Daney wrote:
On 09/16/2013 05:05 PM, Josef Bacik wrote:
On Mon, Sep 16, 2013 at 04:05:47PM -0700, Andrew Morton wrote:
On Fri, 30 Aug 2013 10:14:01 -0400
on to the rwsem in either
read or write. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V1-V2: took everybodys suggestions and simplified it to just one function in
rwsem.h so it works for both the spinlock case and non-spinlock case.
include/linux/rwsem.h | 13 +
1 file
-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent-tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index cfb3cf7..cc074c34 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -442,7 +442,8 @@ next
On Thu, Sep 19, 2013 at 06:57:27PM -0400, Peter Hurley wrote:
On 09/19/2013 11:48 AM, Josef Bacik wrote:
Btrfs needs a simple way to know if it needs to let go of it's read lock on a
rwsem. Introduce rwsem_is_contended to check to see if there are any
waiters on
this rwsem currently
From: Josef Bacik jba...@fusionio.com
We can starve out the transaction commit with a bunch of caching threads all
running at the same time. This is because we will only drop the
extent_commit_sem if we need_resched(), which isn't likely to happen since we
will be reading a lot from the disk so
From: Josef Bacik jba...@fusionio.com
Btrfs needs a simple way to know if it needs to let go of it's read lock on a
rwsem. Introduce rwsem_is_contended to check to see if there are any waiters on
this rwsem currently. This is just a hueristic, it is meant to be light and not
100% accurate
On 01/13/2014 02:02 PM, Ingo Molnar wrote:
* Josef Bacik jba...@fb.com wrote:
From: Josef Bacik jba...@fusionio.com
Btrfs needs a simple way to know if it needs to let go of it's read lock on a
rwsem. Introduce rwsem_is_contended to check to see if there are any waiters on
this rwsem
On Wed, Oct 09, 2013 at 08:40:30PM -0300, Geyslan G. Bem wrote:
In some cases, add_inode_ref() is returning without freeing
the 'name' pointer.
Added bail out to explicitly call kfree when necessary.
Signed-off-by: Geyslan G. Bem geys...@gmail.com
---
fs/btrfs/tree-log.c | 10 --
On Sun, Sep 01, 2013 at 01:32:36AM -0700, Michel Lespinasse wrote:
Hi Josef,
On Fri, Aug 30, 2013 at 7:14 AM, Josef Bacik jba...@fusionio.com wrote:
Btrfs uses an rwsem to control access to its extent tree. Threads will
hold a
read lock on this rwsem while they scan the extent tree
On Sat, Aug 31, 2013 at 04:51:36PM +0200, Peter Zijlstra wrote:
On Fri, Aug 30, 2013 at 10:14:01AM -0400, Josef Bacik wrote:
Btrfs uses an rwsem to control access to its extent tree. Threads will
hold a
read lock on this rwsem while they scan the extent tree, and if
need_resched
On Wed, Sep 04, 2013 at 07:46:56AM -0400, Peter Hurley wrote:
On 09/03/2013 09:18 AM, Josef Bacik wrote:
On Mon, Sep 02, 2013 at 01:18:08PM -0400, Peter Hurley wrote:
On 09/01/2013 04:32 AM, Michel Lespinasse wrote:
Hi Josef,
On Fri, Aug 30, 2013 at 7:14 AM, Josef Bacik jba...@fusionio.com
to allow the commit to continue.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
I've cc'ed people who seemed like they may be in charge/familiar with this code,
hopefully I got the right people.
include/linux/rwsem.h |1 +
lib/rwsem.c | 17 +
2 files changed
On Mon, Sep 02, 2013 at 01:18:08PM -0400, Peter Hurley wrote:
On 09/01/2013 04:32 AM, Michel Lespinasse wrote:
Hi Josef,
On Fri, Aug 30, 2013 at 7:14 AM, Josef Bacik jba...@fusionio.com wrote:
Btrfs uses an rwsem to control access to its extent tree. Threads will
hold a
read lock
On Fri, Sep 20, 2013 at 07:12:47AM +0200, Ingo Molnar wrote:
* Josef Bacik jba...@fusionio.com wrote:
We can starve out the transaction commit with a bunch of caching threads
all running at the same time. This is because we will only drop the
extent_commit_sem if we need_resched
, and they'd block in
the down_read() because there's a writer waiting.
So there's a guarantee of forward progress. This should answer akpm's
concern I think.
Thanks,
Acked-by: Ingo Molnar mi...@kernel.org
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent-tree.c | 3 ++-
1 file
on to the rwsem in either
read or write. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V2-V3: fixed the comment and simplified the function as per Peter's
suggestions.
V1-V2: took everybodys suggestions and simplified it to just one function in
rwsem.h so it works for both the spinlock
of your tree, hopefully that's the right thing.
Thanks,
Josef Bacik (3):
Btrfs: update drop progress before stopping snapshot dropping
Btrfs: fix lock leak when resuming snapshot deletion
Btrfs: re-add root to dead root list if we stop dropping it
Stefan Behrens (1):
Btrfs
On 01/08/2014 05:46 AM, Kusanagi Kouichi wrote:
EXDEV seems an appropriate error if an operation fails bacause it
crosses file system boundaries.
Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp
---
fs/btrfs/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 01/29/2014 10:54 PM, Fengguang Wu wrote:
Hi Steven,
We noticed xfstests generic/299 TFAIL on btrfs since
commit 9fe55eea7e4b444bafc42facc2d1d2847275
Author: Steven Whitehouse swhit...@redhat.com
AuthorDate: Fri Jan 24 14:42:22 2014 +
Commit: Al Viro v...@zeniv.linux.org.uk
On Fri, Aug 09, 2013 at 02:30:38PM +0200, Andreas Schwab wrote:
Andreas Schwab sch...@linux-m68k.org writes:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
The bigger problem is that stripe_nr is u64, this is completely
this is the correct fix, it has fixed the problem
for us. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
NOTE: I looked at MAINTAINERS to see if there was a perf list and it didn't look
like there was one, sorry if this is the wrong place to send patches to.
tools/perf/builtin-script.c | 4 +++-
1 file
On 03/26/2014 03:27 PM, David Ahern wrote:
On 3/26/14, 12:57 PM, Josef Bacik wrote:
We are trying to debug a problem internally and noticed that if we use
perf
record -g -e tracepoint and then try to use perf script to get the
events and
their backtraces that we weren't getting the backtraces
I was on vacation last week, I'll update btrfs-next today once we are happy
with integration. Thanks,
Josef
Sasha Levin sasha.le...@oracle.com wrote:
On 04/07/2014 01:17 PM, Chris Mason wrote:
On 04/07/2014 12:54 PM, David Sterba wrote:
On Fri, Apr 04, 2014 at 05:15:23PM -0400, Sasha
On Thu, Jun 27, 2013 at 10:58:24AM -0400, Dave Jones wrote:
Another bug caused by this script.
https://github.com/kernelslacker/io-tests/blob/master/setup.sh
WARNING: at kernel/lockdep.c:708 __lock_acquire+0x183b/0x1b70()
Modules linked in: sctp lec bridge 8021q garp stp mrp fuse dlci tun
a place in the generic
trace-cmd tool. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
Makefile | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index cbe0eb9..df5ec72 100644
--- a/Makefile
+++ b/Makefile
@@ -47,7 +47,10 @@ html_install
to a pr_stat(). Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
parse-utils.c | 6 --
plugin_function.c | 1 +
trace-cmd-local.h | 1 +
trace-cmd.c | 1 +
trace-cmd.h | 2 --
trace-input.c | 2 +-
trace-local.h | 1 +
trace-recorder.c | 1 +
trace-util.c | 1 +
9
Hello,
I'm trying to build some custom tracing tools on top of trace-cmd but they
aren't really usefull outside of Facebook so I don't want to shove them into the
actual trace-cmd project. Instead I'd like to be able to just build libtracecmd
and install that as well as the necessary header
On 07/10/2014 06:53 PM, Steven Rostedt wrote:
On Thu, 10 Jul 2014 17:22:45 -0400
Josef Bacik jba...@fb.com wrote:
Hello,
I'm trying to build some custom tracing tools on top of trace-cmd but they
aren't really usefull outside of Facebook so I don't want to shove them into the
actual trace-cmd
Sometimes the comm field in the trace.dat file can be empty which means that the
event parsing stuff can pass a NULL into pevent_register_comm. To fix this just
check if we are NULL and generate a bogus comm name for that PID. This keeps us
from segfaulting. Thanks,
Signed-off-by: Josef Bacik
On 05/16/2014 05:50 PM, Daniel Phillips wrote:
We would like to offer Tux3 for review for mainline merge. We have prepared a
new repository suitable for pulling:
;
- } if (ret) {
+ }
+ if (ret) {
ins_nr = 0;
btrfs_release_path(path);
continue;
Nope that's right, thanks,
Reviewed-by: Josef Bacik jba...@fb.com
--
To unsubscribe from this list
When trying to use the python library it was giving me an error about not being
able to resolve tracecmd_stat_cpu. This is because we weren't linking
trace-record.o to ctracecmd.so. Fix this in the makefile and now I can import
trace-cmd in python properly. Thanks,
Signed-off-by: Josef Bacik
On 07/28/2014 04:57 AM, Takashi Iwai wrote:
We've got bug reports that btrfs crashes when quota is enabled on
32bit kernel, typically with the Oops like below:
BUG: unable to handle kernel NULL pointer dereference at 0004
IP: [f9234590] find_parent_nodes+0x360/0x1380 [btrfs]
*pde =
to add.
I'm open to suggestions on how to fix this properly. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
Sorry I fucked up my original submission, if this resend hits you twice I
apologize.
arch/x86/kernel/smpboot.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff
On 07/28/2014 12:39 PM, Peter Zijlstra wrote:
On Mon, Jul 28, 2014 at 12:28:39PM -0400, Josef Bacik wrote:
We have these processors with this Cluster on die feature which shares numa
nodes between cores on different sockets.
Uhm, what?! I know AMD has chips that have two nodes per package
On 07/30/2014 05:57 AM, Takashi Iwai wrote:
At Mon, 28 Jul 2014 16:01:55 +0200,
Takashi Iwai wrote:
At Mon, 28 Jul 2014 15:48:41 +0200,
Takashi Iwai wrote:
At Mon, 28 Jul 2014 09:16:48 -0400,
Josef Bacik wrote:
On 07/28/2014 04:57 AM, Takashi Iwai wrote:
We've got bug reports that btrfs
On 07/30/2014 11:05 AM, Takashi Iwai wrote:
At Wed, 30 Jul 2014 17:01:52 +0200,
Takashi Iwai wrote:
At Wed, 30 Jul 2014 10:29:46 -0400,
Josef Bacik wrote:
On 07/30/2014 05:57 AM, Takashi Iwai wrote:
At Mon, 28 Jul 2014 16:01:55 +0200,
Takashi Iwai wrote:
At Mon, 28 Jul 2014 15:48:41 +0200
On 07/30/2014 11:52 AM, Takashi Iwai wrote:
At Wed, 30 Jul 2014 11:40:14 -0400,
Josef Bacik wrote:
On 07/30/2014 11:05 AM, Takashi Iwai wrote:
At Wed, 30 Jul 2014 17:01:52 +0200,
Takashi Iwai wrote:
At Wed, 30 Jul 2014 10:29:46 -0400,
Josef Bacik wrote:
On 07/30/2014 05:57 AM, Takashi
On 07/22/2014 08:58 AM, Johannes Berg wrote:
On Mon, 2014-07-21 at 17:01 -0400, Steven Rostedt wrote:
Cc'd my python gurus.
Acks?
When trying to use the python library it was giving me an error about not being
able to resolve tracecmd_stat_cpu. This is because we weren't linking
On 07/30/2014 12:35 PM, Takashi Iwai wrote:
At Wed, 30 Jul 2014 12:01:31 -0400,
Josef Bacik wrote:
On 07/30/2014 11:52 AM, Takashi Iwai wrote:
At Wed, 30 Jul 2014 11:40:14 -0400,
Josef Bacik wrote:
On 07/30/2014 11:05 AM, Takashi Iwai wrote:
At Wed, 30 Jul 2014 17:01:52 +0200,
Takashi Iwai
to make sure
ring_buffer_empty() is going to be correct.
cc: ka...@fb.com
cc: rost...@goodmis.org
Signed-off-by: Josef Bacik jba...@fb.com
---
kernel/trace/ring_buffer.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace
On 07/30/2014 04:42 PM, Nicholas Krause wrote:
This patch removes the lines for releasing the page cache in certain
files as this may aid in perfomance with writes in the compression
rountines of btrfs. Please note that this patch has not been tested
on my own hardware due to no compression
a pending
stack trace, so we got garbage in the call chain and hilarity ensued. Fix this
by only pushing the pending call chain if there actually is one, and also don't
reset the current call chain if there isn't actually one there either. This
fixed my segfault. Thanks,
Signed-off-by: Josef
it again.
Thanks,
Josef
Nick Krause xerofo...@gmail.com wrote:
On Wed, Jul 30, 2014 at 4:51 PM, Zach Brown z...@zabbo.net wrote:
On Wed, Jul 30, 2014 at 04:47:12PM -0400, Josef Bacik wrote:
On 07/30/2014 04:42 PM, Nicholas Krause wrote:
This patch removes the lines for releasing the page cache
Oops crap that's the second time I've done that this week. When I get to my
computer I'll send the actual fix by itself, sorry about that,
Josef
Steven Rostedt rost...@goodmis.org wrote:
On Wed, 30 Jul 2014 16:54:45 -0400
Josef Bacik jba...@fb.com wrote:
I have a trace.dat file where we
a pending
stack trace, so we got garbage in the call chain and hilarity ensued. Fix this
by only pushing the pending call chain if there actually is one, and also don't
reset the current call chain if there isn't actually one there either. This
fixed my segfault. Thanks,
Signed-off-by: Josef
On 10/14/2014 03:27 AM, Davidlohr Bueso wrote:
Hello,
I'm getting massive amounts of cpu soft lockups in Linus's tree for
today. This occurs almost immediately and is very reproducible in aim7
disk workloads using btrfs:
I'm trying to reproduce but it's not popping for me. What is the setup
messages from within
my python script.
Signed-off-by: Josef Bacik jba...@fb.com
---
ctracecmd.i | 30 ++
1 file changed, 30 insertions(+)
diff --git a/ctracecmd.i b/ctracecmd.i
index 3b80f01..e91d068 100644
--- a/ctracecmd.i
+++ b/ctracecmd.i
@@ -34,6 +34,36 @@ static
This allows tools linking against the trace-cmd libraries to supress this output
if it is not necessary for them.
Signed-off-by: Josef Bacik jba...@fb.com
---
trace-input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace-input.c b/trace-input.c
index 8118b22..090ee59
array from python. So add a new c
binding to specially read the addr array and go ahead and look up the function
names for the addr and return those strings. With this I can now pull the
function names for a kernel_stack event from the python library. Thanks,
Signed-off-by: Josef Bacik jba
On 09/24/2014 12:12 PM, Steven Rostedt wrote:
On Wed, 24 Sep 2014 12:03:29 -0400
Josef Bacik jba...@fb.com wrote:
The way the ftrace kernel_stack event is handled doesn't work right with the
normal event reading stuff in python. The raw buffer read stuff expects the
size of the event
shows up as a
size of 0. So change this to __array and set the len to FTRACE_STACK_ENTRIES
since this is what we actually do in practice and matches how user_stack_trace
works. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
kernel/trace/trace_entries.h | 2 +-
1 file changed, 1 insertion
with it, but I sent it in July I think. If these are
acceptable you can just pull from
https://github.com/josefbacik/trace-cmd.git for-steve
Here is the shortlog
Josef Bacik (4):
trace-cmd: make sure we have a pending pid in trace-hist
trace-cmd: add trace-record.o to the python
bindings to read
these arrays in, lookup the function and append them to a python list.
Signed-off-by: Josef Bacik jba...@fb.com
---
NOTE: This patch replaces the one I sent yesterday
trace-cmd: add helper to read kernel_stack functions
This is cleaner and gives us a nice list of the functions
On 12/10/2014 10:34 PM, Mike Galbraith wrote:
On Wed, 2014-12-10 at 16:48 -0500, Josef Bacik wrote:
On 12/10/2014 01:23 AM, Mike Galbraith wrote:
On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote:
This patch moves stat stuff to after the schedule, right as we are waking up,
But sleep
add the scheduler latency to the sleep stats, so I've added 3 new
fields in the scheduler stats to keep track of the last sleep time so that if
any of these are set we know to trigger the trace points. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
V1-V2: left the stat collection the way
On 12/15/2014 05:16 AM, Peter Zijlstra wrote:
On Thu, Dec 11, 2014 at 10:59:55AM -0500, Josef Bacik wrote:
The schedule stats currently spit out once the entity is being queued, which
means if we have stack traces enabled we will get the stack trace of the waker,
not of the task being woken
.
This is an important fix for us and anybody else who wants to do latency
debugging in production at a large scale. Thanks
Signed-off-by: Josef Bacik jba...@fb.com
---
kernel/sched/core.c | 14 --
kernel/sched/fair.c | 14 ++
kernel/sched/sched.h | 1 +
3 files changed, 11 insertions
On 12/10/2014 01:23 AM, Mike Galbraith wrote:
On Tue, 2014-12-09 at 13:21 -0500, Josef Bacik wrote:
This patch moves stat stuff to after the schedule, right as we are waking up,
But sleep/block ends when the task is awakened/enqueued, not when it
gets the CPU. You're adding scheduling
On 02/20/2015 04:20 PM, Omar Sandoval wrote:
On Tue, Feb 17, 2015 at 02:51:06AM -0800, Omar Sandoval wrote:
Hi,
As it turns out, running with low memory is a really easy way to shake
out undesirable behavior in Btrfs. This can be especially bad when
considering that a memory limit is really
On 03/16/2015 08:27 AM, Jan Kara wrote:
Hello,
On Tue 10-03-15 15:45:23, Josef Bacik wrote:
From: Dave Chinner dchin...@redhat.com
The per-superblock inode list and lock is a bottleneck for systems
that cycle inodes in and out of cache concurrently. The global lock
is a limiting factor
little work to do.
This also means that we have to remove the inodes from the writeback
list during eviction. Do this in inode_wait_for_writeback() once
all writeback on the inode is complete.
Signed-off-by: Dave Chinner dchin...@redhat.com
Signed-off-by: Josef Bacik jba...@fb.com
---
V2-V3
~100 million
inodes. This makes one processor a very unhappy person, so add a cond_resched()
in dispose_list() and cond_resched_lock() in the eviction isolation function to
combat this. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
fs/inode.c | 10 ++
1 file changed, 10 insertions
sync(2) IO
completion walk per superblock superblock at a time and hence avoid
contention being triggered by concurrent sync(2) calls.
Signed-off-by: Dave Chinner dchin...@redhat.com
Signed-off-by: Josef Bacik jba...@fb.com
Reviewed-by: Jan Kara j...@suse.cz
---
fs/fs-writeback.c | 11
Here is the update to the patches based on comments from Al and Jan. The
changes since V1 are
- Dropped the IOP_NOTHASHED patch and replaced it wit the hlist_fake patch as
per Al's suggestion.
- Dropped inode: convert per-sb inode list to a list_lru since Jan has found
some issues with it
hash lock in evict
basd on Al's suggestions. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
Reviewed-by: Jan Kara j...@suse.cz
---
include/linux/fs.h | 2 +-
include/linux/list.h | 5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
-by: Dave Chinner dchin...@redhat.com
Signed-off-by: Josef Bacik jba...@fb.com
Reviewed-by: Jan Kara j...@suse.cz
---
fs/fs-writeback.c | 20 ++--
fs/inode.c | 6 +++---
include/linux/fs.h | 2 +-
mm/backing-dev.c | 8
4 files changed, 18 insertions(+), 18
little work to do.
This also means that we have to remove the inodes from the writeback
list during eviction. Do this in inode_wait_for_writeback() once
all writeback on the inode is complete.
Signed-off-by: Dave Chinner dchin...@redhat.com
Signed-off-by: Josef Bacik jba...@fb.com
---
fs/fs
the
writeback list.
Signed-off-by: Dave Chinner dchin...@redhat.com
Signed-off-by: Josef Bacik jba...@fb.com
Reviewed-by: Jan Kara j...@suse.cz
---
fs/fs-writeback.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 82b0f43..aa0de0f
. This doesn't get
rid of contention as the locks still have global CPU scope, but it
does isolate operations on different superblocks form each other.
Signed-off-by: Dave Chinner dchin...@redhat.com
Signed-off-by: Josef Bacik jba...@fb.com
Reviewed-by: Jan Kara j...@suse.cz
---
fs/block_dev.c
devices.
Signed-off-by: Dave Chinner dchin...@redhat.com
Signed-off-by: Josef Bacik jba...@fb.com
Reviewed-by: Jan Kara j...@suse.cz
---
fs/fs-writeback.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index e907052..a9ff2b7 100644
--- a/fs/fs
From: Dave Chinner dchin...@redhat.com
When competing sync(2) calls walk the same filesystem, they need to
walk the list of inodes on the superblock to find all the inodes
that we need to wait for IO completion on. However, when multiple
wait_sb_inodes() calls do this at the same time, they
From: Dave Chinner dchin...@redhat.com
There's a small consistency problem between the inode and writeback
naming. Writeback calls the for IO inode queues b_io and
b_more_io, but the inode calls these the writeback list or
i_wb_list. This makes it hard to an new under writeback list to
the inode,
These are patches that Dave Chinner wrote two years ago that are still very much
needed today. I recently ran into a problem where I had millions of inodes that
needed to be evicted at unmount time and it soft locked up the box and kept any
other file system from doing work. These patches fix
From: Dave Chinner dchin...@redhat.com
The per-superblock inode list and lock is a bottleneck for systems
that cycle inodes in and out of cache concurrently. The global lock
is a limiting factor.
Most of the additions to the sb inode list occur on the CPU that
allocated the inode, and most of
From: Dave Chinner dchin...@redhat.com
wait_sb_inodes() current does a walk of all inodes in the filesystem
to find dirty one to wait on during sync. This is highly
inefficient and wastes a lot of CPU when there are lots of clean
cached inodes that we don't need to wait on.
To avoid this all
From: Dave Chinner dchin...@redhat.com
Doing writeback on lots of little files causes terrible IOPS storms
because of the per-mapping writeback plugging we do. This
essentially causes imeediate dispatch of IO for each mapping,
regardless of the context in which writeback is occurring.
IOWs,
1 - 100 of 892 matches
Mail list logo
