On Tue, May 29, 2012 at 02:24:58PM +0900, Tejun Heo wrote:

quoted

So in practice there's no extra stack usage. Whether this is an
optimization we want to depend I'm not going to say; I suspect it's
pretty safe w.r.t. the optimizer but it's definitely sketchy and if at
some point someone came along and switched it to the uninline version
we'd have problems.

I don't think we can depend on that.  Note that compiler may as well
decide not to inline an inline function (e.g. if it sees many calling
instances).  Depending on such behavior is way too fragile.

Bah, I forgot about the compiler uninlining stuff. There's
__always_inline, but... yeah, I agree, too dangerous.

quoted

So we might want to leave this one open coded. Which would make me sad,
but I can't think of a sane way of implementing generic rb_search() that
doesn't require passing it a type t to compare against.

I don't know either.  Open coding isn't the end of the world but I
suspect a lot of data structures which go on rbtree wouldn't be stack
friendly, so having common helper which can't handle that might not be
too helpful.

There's > 100 users in the kernel, I have no clue what the average size
of the containing struct is.

I think I'm gonna split rb_search() out into its own patch, as
rb_insert() fortunately doesn't have this problem.

I'm starting to think the sanest solution is a macro (not quite my
original RB_SEARCH() macro, though).