All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Christoph Hellwig <hch@lst.de>, Li Zefan <lizf@cn.fujitsu.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Johannes Berg <johannes.berg@intel.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Tom Zanussi <tzanussi@gmail.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andi Kleen <andi@firstfloor.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Paul Menage <menage@google.com>,
	David Rientjes <rientjes@google.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Cedric Le Goater <clg@vnet.ibm.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [RFC PATCH] Prio_heap: heap_remove(), heap_maximum(), heap_replace() and heap_cherrypick()
Date: Thu, 7 Oct 2010 02:24:14 -0400	[thread overview]
Message-ID: <20101007062414.GA28631@Krystal> (raw)
In-Reply-To: <20101007034234.GM4195@balbir.in.ibm.com>

* Balbir Singh (balbir@linux.vnet.ibm.com) wrote:
> * Mathieu Desnoyers <mathieu.desnoyers@efficios.com> [2010-10-06 14:03:23]:
> 
> > These added interfaces lets prio_heap users lookup the top of heap item without
> > performing any insertion, perform removal of the topmost heap entry, and also
> > replacement of topmost heap entry. This is useful if one need to use the result
> > of the lookup to determine if the current maximum should simply be removed or if
> > it should be replaced.
> > 
> > This is used by the Generic Ring Buffer to perform timestamp-based fusion-merge
> > of per-cpu buffer records into a single stream.
> >
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> > Cc: Paul Menage <menage@google.com>
> > Cc: David Rientjes <rientjes@google.com>
> > Cc: Nick Piggin <nickpiggin@yahoo.com.au>
> > Cc: Balbir Singh <balbir@in.ibm.com>
> > Cc: Cedric Le Goater <clg@fr.ibm.com>
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > ---
> 
> The patchset looks good to me, one comment on cherry picking below
> 
> Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>

Thanks!

[...]
> > +/**
> > + * heap_cherrypick - remove a given element from the heap
> > + * @heap: the heap to be operated on
> > + * @p: the element
> > + *
> > + * Remove the given element from the heap. Return the element if present, else
> > + * return NULL. This algorithm has a complexity of O(n), which is higher than
> > + * O(log(n)) provided by the rest of this API.
> > + */
> > +extern void *heap_cherrypick(struct ptr_heap *heap, void *p);
> 
> One way to reduce cherrypick'ing in O(n) if n is large, is to sort the
> entire heap using heapify() and then doing a binary search. The cost
> of sorting is high, so it depends on how often and in what phases we
> cherry pick.

I need this to implement the ring buffer iterator "reset" primitive, which is
very infrequently called. So for my use-case, I really prefer to keep very fast
add/remove/get max (as implemented currently) without sorting the rest of the
heap. What you propose looks more like a balanced binary tree, which we already
have in the kernel, but clearly adds some overhead by requiring to keep the
whole tree sorted.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

      reply	other threads:[~2010-10-07  6:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06 18:03 [RFC PATCH] Prio_heap: heap_remove(), heap_maximum(), heap_replace() and heap_cherrypick() Mathieu Desnoyers
2010-10-07  3:42 ` Balbir Singh
2010-10-07  6:24   ` Mathieu Desnoyers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101007062414.GA28631@Krystal \
    --to=mathieu.desnoyers@efficios.com \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=clg@vnet.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=fweisbec@gmail.com \
    --cc=hch@lst.de \
    --cc=johannes.berg@intel.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=menage@google.com \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tzanussi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.