Pass mp to kmem_alloc and friends?
I had a request for the kmem_alloc deadlock warning to print the filesystem involved.
Any objections to passing mp into kmem_alloc() and friends whenever it's reasonably available from the caller?
It'd be a big mechanical change, don't want to embark on that unless it seems acceptable & useful.
I think we generally know the root causes of the most common deadlock warnings, but it's a warm fuzzy to give as much info as possible.
Heck, I almost wonder if passing a descriptive string in, for at least the problematic cases we know about, i.e. "extent map realloc" so we'd get something like:
XFS (sdb1): myprocess(123) possible memory allocation deadlock size 12345 during extent map realloc in kmem_alloc (mode:0x250)
I dunno ... too much? :)
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 12 lines · Eric Sandeen
I had a request for the
kmem_allocdeadlock warning to print the filesystem involved.Any objections to passing mp into
kmem_alloc()and friends whenever it's reasonably available from the caller?It'd be a big mechanical change, don't want to embark on that unless it seems acceptable & useful.
I think we generally know the root causes of the most common deadlock warnings, but it's a warm fuzzy to give as much info as possible.
Quoted 7 lines
Heck, I almost wonder if passing a descriptive string in, for at least the problematic cases we know about, i.e. "extent map realloc" so we'd get something like:
XFS (sdb1): myprocess(123) possible memory allocation deadlock size 12345 during extent map realloc in
kmem_alloc(mode:0x250)I dunno ... too much? :)
Not enough? What about putting in just enough macro madness to report the name & line number of the calling function in the message?
XFS (sdb1): myprocess(123) possible kmem_alloc deadlock in xfs_eat_my_data.c:5135 (size:12345 mode:0x250)
(or maybe a tracepoint?)
--D
Quoted 7 lines
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 19 lines · Darrick J. Wong
Quoted 18 lines · Eric Sandeen
I had a request for the
kmem_allocdeadlock warning to print the filesystem involved.Any objections to passing mp into
kmem_alloc()and friends whenever it's reasonably available from the caller?It'd be a big mechanical change, don't want to embark on that unless it seems acceptable & useful.
I think we generally know the root causes of the most common deadlock warnings, but it's a warm fuzzy to give as much info as possible.
Heck, I almost wonder if passing a descriptive string in, for at least the problematic cases we know about, i.e. "extent map realloc" so we'd get something like:
XFS (sdb1): myprocess(123) possible memory allocation deadlock size 12345 during extent map realloc in
kmem_alloc(mode:0x250)
Quoted 7 lines
Quoted 1 line
I dunno ... too much? :)
Not enough? What about putting in just enough macro madness to report the name & line number of the calling function in the message?
XFS (sdb1): myprocess(123) possible
kmem_allocdeadlock in xfs_eat_my_data.c:5135 (size:12345 mode:0x250)
Problem with that is the the return address will often just point to a higher level wrapper function, and we are still without any caller context. e.g. if we find the caller is xfs_buf_alloc_maps(), what operation was being performed that needed a new buffer allocated?
IMO, the only thing that will actually be useful for debugging at this point is a full stack dump....
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines · Eric Sandeen
I had a request for the
kmem_allocdeadlock warning to print the filesystem involved.Any objections to passing mp into
kmem_alloc()and friends whenever it's reasonably available from the caller?It'd be a big mechanical change, don't want to embark on that unless it seems acceptable & useful.
I think I hinted at this in the configurable error handling patchset I have so that we could have configurable ENOMEM error handling. My comment in the current commit message for that patch includes this:
| I'm not yet sure how to hook it into the memory allocation calls - | that will be done in a later patch; this just demonstrates how | multiple classes are configured and initialised. It may be that we | don't configure specific errors here - instead configure how we | handle specific types of allocation failure e.g. GFP_KERNEL vs | GFP_NOFS vs allocations inside transactions. Either way, we are | going to need to plumb the error config handler into the | memory allocation code in some manner.
So I think we are going to have to plumb the xfs_mount into these calls at some point in the near future.
Quoted 8 lines
I think we generally know the root causes of the most common deadlock warnings, but it's a warm fuzzy to give as much info as possible.
Heck, I almost wonder if passing a descriptive string in, for at least the problematic cases we know about, i.e. "extent map realloc" so we'd get something like:
XFS (sdb1): myprocess(123) possible memory allocation deadlock size 12345 during extent map realloc in
kmem_alloc(mode:0x250)
If we want more context, then make it an error message that can dump the stack when the error level is turned up. i.e. if we pass in an xfs_mount, we can use XFS_ERROR_REPORT here...
Cheers,
Dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs