[lkml]   [2006]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync
On Mon, 20 Nov 2006, Jens Axboe wrote:

> > > Must we introduce memory allocations in srcu_read_lock()? It makes it
> > > much harder and nastier for me to use. I'd much prefer a failing
> > > init_srcu(), seems like a much better API.
> >
> > Paul agrees with you that allocation failures in init_srcu() should be
> > passed back to the caller, and I certainly don't mind doing so.
> >
> > However we can't remove the memory allocation in srcu_read_lock(). That
> > was the point which started this whole thread: the per-cpu allocation
> > cannot be done statically, and some users of a static SRCU structure can't
> > easily call init_srcu() early enough.
> >
> > Once the allocation succeeds, the overhead in srcu_read_lock() is minimal.
> It's not about the overhead, it's about a potentially problematic
> allocation.

I'm not sure what you mean by "problematic allocation". If you
successfully call init_srcu_struct then the allocation will be taken care
of. Later calls to srcu_read_lock won't experience any slowdowns or

If your call to init_srcu_struct isn't successful then you have to decide
how to handle it. You can ignore the failure and live with degraded
performance (caused by cache-line contention and repeated attempts to do
the per-cpu allocation), or you can give up entirely.

Does this answer your objection? If not, can you explain in more detail
what other features you would like?

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-20 22:43    [W:0.082 / U:0.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site