From: William Lee Irwin III <wli@holomorphy.com>
To: inaky.perez-gonzalez@intel.com
Cc: linux-kernel@vger.kernel.org, robustmutexes@lists.osdl.org
Subject: Re: [RFC/PATCH] FUSYN 5/10: kernel fuqueues
Date: Fri, 12 Dec 2003 11:21:11 -0800 [thread overview]
Message-ID: <20031212192111.GO8039@holomorphy.com> (raw)
In-Reply-To: <0312030051.paLaLbTdPdUbed6dXcEbXdDajbVdUd6c25502@intel.com>
On Wed, Dec 03, 2003 at 12:51:34AM -0800, inaky.perez-gonzalez@intel.com wrote:
> +static inline void __debug_outb (unsigned val, int port) {
> + __asm__ __volatile__ ("outb %b0,%w1" : : "a" (val), "Nd" (port));
> +}
> +static inline unsigned __debug_inb (int port) {
> + unsigned value;
> + __asm__ __volatile__ ("inb %w1,%b0" : "=a" (value) : "Nd" (port));
> + return value;
> +}
> +static inline
> +void __debug_printstr (const char *str) {
> + const int port = 0x03f8;
> + while (*str) {
> + while (!(__debug_inb (port + UART_LSR) & UART_LSR_THRE));
> + __debug_outb (*str++, port+UART_TX);
> + }
> + __debug_outb ('\r', port + UART_TX);
> +}
> +#endif
In general, this kind of debug code shouldn't go in "shipped" patches.
On Wed, Dec 03, 2003 at 12:51:34AM -0800, inaky.perez-gonzalez@intel.com wrote:
> +#define assert(c, a...) do { if ((DEBUG >= 0) && !(c)) BUG(); } while (0)
assert() is a no-no in Linux, for various reasons.
On Wed, Dec 03, 2003 at 12:51:34AM -0800, inaky.perez-gonzalez@intel.com wrote:
> + * FIXME: is it worth to have get/put? maybe they should be enforced
> + * for every fuqueue, this way we don't have to query the ops
> + * structure for the get/put method and if it is there, call
> + * it. We'd have to move the get/put ops over to the vlocator,
> + * but that's not much of a problem.
> + * The decission factor is that an atomic operation needs to
> + * lock the whole bus and is not as scalable as testing a ptr
> + * for NULLness.
> + * For simplicity, probably the idea of forcing the refcount in
> + * the fuqueue makes sense.
Basically, if there aren't multiple implementations of ->get()/->put()
that need to be disambiguated, this should get left out.
On Wed, Dec 03, 2003 at 12:51:34AM -0800, inaky.perez-gonzalez@intel.com wrote:
> +#if DEBUG > 0
> +/* BUG_ON() firing? Temporary fix, do you have CONFIG_PREEMPT enabled?
> + * either that or disable DEBUG (force #define it to zero). */
> +#define CHECK_IRQs() do { BUG_ON (!in_atomic()); } while (0)
> +#else
> +#define CHECK_IRQs() do {} while (0)
> +#endif
This kind of thing isn't good to have in shipped patches either.
On Wed, Dec 03, 2003 at 12:51:34AM -0800, inaky.perez-gonzalez@intel.com wrote:
> +/* Priority-sorted list */
> +struct plist {
> + unsigned prio;
> + struct list_head node;
> +};
Maybe the expectation is for short lists, but it might be better to use
an rbtree or other sublinear insertion/removal structure for this. It
would be nice if we had a generic heap structure for this sort of affair.
On Wed, Dec 03, 2003 at 12:51:34AM -0800, inaky.perez-gonzalez@intel.com wrote:
> +void fuqueue_chprio (struct task_struct *task)
> +{
> + struct fuqueue_ops *ops;
> + struct fuqueue *fuqueue;
> + struct fuqueue_waiter *w;
> + int prio = task->prio;
> + unsigned long flags;
> +
> + __ftrace (1, "(%p [%d])\n", task, task->pid);
> + CHECK_IRQs();
> +
> + local_irq_save (flags);
> + preempt_disable();
> + get_task_struct (task);
> +next:
> + /* Who is the task waiting for? safely acquire and lock it */
> + _raw_spin_lock (&task->fuqueue_wait_lock);
> + fuqueue = task->fuqueue_wait;
> + if (fuqueue == NULL) /* Ok, not waiting */
> + goto out_task_unlock;
> + if (!_raw_spin_trylock (&fuqueue->lock)) { /* Spin dance... */
> + _raw_spin_unlock (&task->fuqueue_wait_lock);
> + goto next;
> + }
> + ops = fuqueue->ops;
> + if (ops->get)
> + ops->get (fuqueue);
> +
> + w = task->fuqueue_waiter;
> + _raw_spin_unlock (&task->fuqueue_wait_lock);
> + put_task_struct (task);
> +
> + /* Ok, we need to propagate the prio change to the fuqueue */
> + ops = fuqueue->ops;
> + task = ops->chprio (task, fuqueue, w);
> + if (task == NULL)
> + goto out_fuqueue_unlock;
> +
> + /* Do we need to propagate to the next task */
> + get_task_struct (task);
> + _raw_spin_unlock (&fuqueue->lock);
> + if (ops->put)
> + ops->put (fuqueue);
> + ldebug (1, "__set_prio (%d, %d)\n", task->pid, prio);
> + __set_prio (task, prio);
> + goto next;
> +
> +out_fuqueue_unlock:
> + _raw_spin_unlock (&fuqueue->lock);
> + if (ops->put)
> + ops->put (fuqueue);
> + goto out;
> +
> +out_task_unlock:
> + _raw_spin_unlock (&task->fuqueue_wait_lock);
> + put_task_struct (task);
> +out:
> + local_irq_restore (flags);
> + preempt_enable();
> + return;
Heavy use of _raw_spin_lock() like this is a poor practice.
On Wed, Dec 03, 2003 at 12:51:34AM -0800, inaky.perez-gonzalez@intel.com wrote:
> +/** Fuqueue operations for usage within the kernel */
> +struct fuqueue_ops fuqueue_ops = {
> + .get = NULL,
> + .put = NULL,
> + .wait_cancel = __fuqueue_wait_cancel,
> + .chprio = __fuqueue_chprio
> +};
If this is all ->get() and ->put() are going to be, why bother?
-- wli
next prev parent reply other threads:[~2003-12-12 19:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0312030051..akdxcwbwbHdYdmdSaFbbcycyc3a~bzd25502@intel.com>
2003-12-03 8:51 ` [RFC/PATCH] FUSYN 5/10: kernel fuqueues inaky.perez-gonzalez
2003-12-03 8:51 ` [RFC/PATCH] FUSYN 6/10: user space/kernel space tracker inaky.perez-gonzalez
2003-12-03 8:51 ` [RFC/PATCH] FUSYN 7/10: user space fuqueues inaky.perez-gonzalez
2003-12-03 8:51 ` [RFC/PATCH] FUSYN 8/10: kernel fulocks inaky.perez-gonzalez
2003-12-11 23:30 ` [RFC/PATCH] FUSYN 5/10: kernel fuqueues Matt Mackall
2003-12-11 23:55 ` Gene Heskett
2003-12-14 16:15 ` Pavel Machek
2003-12-12 19:21 ` William Lee Irwin III [this message]
2003-12-12 0:06 Perez-Gonzalez, Inaky
2003-12-12 2:57 ` Matt Mackall
-- strict thread matches above, loose matches on Subject: below --
2003-12-12 3:15 Perez-Gonzalez, Inaky
2003-12-12 3:23 ` Matt Mackall
2003-12-12 22:43 ` Jamie Lokier
2003-12-12 3:26 Perez-Gonzalez, Inaky
2003-12-12 23:02 watermodem
2003-12-13 6:09 ` Valdis.Kletnieks
2003-12-13 1:05 Perez-Gonzalez, Inaky
2004-01-14 22:50 [RFC/PATCH] FUSYN 4/10: Support for ia64 inaky.perez-gonzalez
2004-01-14 22:50 ` [RFC/PATCH] FUSYN 5/10: kernel fuqueues inaky.perez-gonzalez
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=20031212192111.GO8039@holomorphy.com \
--to=wli@holomorphy.com \
--cc=inaky.perez-gonzalez@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robustmutexes@lists.osdl.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox