On Wed, Sep 30, 2015 at 11:19:25AM -0500, Felipe Balbi wrote:
> On Mon, Sep 28, 2015 at 03:35:14PM +0200, Christoph Hellwig wrote:
> > On Sun, Sep 27, 2015 at 10:50:53AM -0500, Felipe Balbi wrote:
> > > this (and the other helper below) could be macros just fine.
> >
> > They could, but they
On Wed, Sep 30, 2015 at 11:32:19AM -0500, Felipe Balbi wrote:
> On Wed, Sep 30, 2015 at 12:20:46PM -0400, Tejun Heo wrote:
> > On Wed, Sep 30, 2015 at 11:19:25AM -0500, Felipe Balbi wrote:
> > > On Mon, Sep 28, 2015 at 03:35:14PM +0200, Christoph Hellwig wrote:
> > > &
On Wed, Sep 30, 2015 at 11:43:01AM -0500, Felipe Balbi wrote:
> Seems like there are *ton* of uses of container_of() wrapped within a simple
> macro. What convention are you talking about, again ?
The convention of using inline functions over macros when possible.
We don't do that all the time
Hello, Christoph.
On Fri, Sep 25, 2015 at 06:49:38AM -0700, Christoph Hellwig wrote:
> Add methods to struct configfs_attribute to directly show and store
> attributes without adding boilerplate code to every user. In addition
> to the methods this also adds 3 helper macros to define read/write,
WQ_NON_REENTRANT no-op and the flag is going away. Remove its usages.
This patch doesn't introduce any behavior changes.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Steven Whitehouse swhit...@redhat.com
Cc: cluster-devel@redhat.com
---
fs/gfs2/main.c | 2 +-
1 file changed, 1 insertion(+), 1
WQ_NON_REENTRANT no-op and the flag is going away. Remove its usages.
This patch doesn't introduce any behavior changes.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Christine Caulfield ccaul...@redhat.com
Cc: David Teigland teigl...@redhat.com
Cc: cluster-devel@redhat.com
---
fs/dlm/ast.c | 5
Hello, Kent.
On Tue, Jun 18, 2013 at 05:02:30PM -0700, Kent Overstreet wrote:
With the new ida implementation, that doesn't work anymore - the new ida
code grows its bitmap tree by reallocating the entire thing in power of
two increments. Doh.
So, I'm not sure about the single contiguous
On Wed, Jun 19, 2013 at 04:33:44PM -0700, Kent Overstreet wrote:
With respect to performance, strongly disagree. Leaving pointers out of
the interior nodes cuts our space requirements by a factor of _64_ -
that's huge, and with data structures the dominating factors w.r.t.
performance tend to
idr_for_each_entry() loop. It goes on top so that it matches
the operation order in recover_idr_del().
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Christine Caulfield ccaul...@redhat.com
Cc: David Teigland teigl...@redhat.com
Cc: cluster-devel@redhat.com
---
fs/dlm/lockspace.c | 1
Convert recover_idr_clear() to use idr_for_each_entry() instead of
idr_for_each(). It's somewhat less efficient this way but it
shouldn't matter in an error path. This is to help with deprecation
of idr_remove_all().
Only compile tested.
Signed-off-by: Tejun Heo t...@kernel.org
Cc: Christine
offset - ie. use round_up(id + 1, slot_distance) instead of
id += slot_distance.
Signed-off-by: Tejun Heo t...@kernel.org
Reported-by: David Teigland teigl...@redhat.com
Cc: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
lib/idr.c |9 -
1 file changed, 8 insertions(+), 1
On Sat, Feb 02, 2013 at 03:10:48PM -0800, Tejun Heo wrote:
Fix it by ensuring proceeding to the next slot doesn't carry over the
unaligned offset - ie. use round_up(id + 1, slot_distance) instead of
id += slot_distance.
Signed-off-by: Tejun Heo t...@kernel.org
Reported-by: David Teigland
Hello, David.
Sorry about the delay.
On Wed, Jan 30, 2013 at 04:24:18PM -0500, David Teigland wrote:
Unfortunately, the list_for_each_entry doesn't seem to be clearing
everything. I've seen warning: recover_list_count 39 at the end of that
function.
I don't want to pretend to
Hello, David.
On Thu, Jan 31, 2013 at 03:53:20PM -0800, Tejun Heo wrote:
The function description is misleading. The function does search
inclusive range and needs explicit cursor increment to make progress.
Weird that it doesn't work. Looking into it. I'll write when I know
more
Hello, David.
On Fri, Feb 01, 2013 at 12:44:43PM -0500, David Teigland wrote:
I already tried my own version of this, but used idr_for_each_entry a
second time. Unfortunately, the number it found and printed did not match
recover_list_count.
warning: recover_list_count 566
It printed
15 matches
Mail list logo
