[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090310170607.GB22897@elte.hu>
Date: Tue, 10 Mar 2009 18:06:07 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Alan Stern <stern@...land.harvard.edu>
Cc: prasad@...ux.vnet.ibm.com,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Roland McGrath <roland@...hat.com>
Subject: Re: [patch 04/11] Introduce virtual debug register in
thread_struct and wrapper-routines around process related functions
* Alan Stern <stern@...land.harvard.edu> wrote:
> On Tue, 10 Mar 2009, Ingo Molnar wrote:
>
> > and why is this:
> >
> > > @@ -427,13 +427,9 @@ struct thread_struct {
> > > unsigned long ip;
> > > unsigned long fs;
> > > unsigned long gs;
> > > - /* Hardware debugging registers: */
> > > - unsigned long debugreg0;
> > > - unsigned long debugreg1;
> > > - unsigned long debugreg2;
> > > - unsigned long debugreg3;
> > > - unsigned long debugreg6;
> > > - unsigned long debugreg7;
> > > + /* Hardware breakpoint info */
> > > + unsigned long vdr6;
> > > + struct thread_hw_breakpoint *hw_breakpoint_info;
> >
> > detached from thread_struct? There's a lot of complications
> > (alloc/free, locking, etc.) from this for no good reason - the
> > hardware-breakpoints info structure is alway per thread and is
> > quite small, so there's no reason not to embedd it directly
> > inside thread_struct.
>
> The only reason for separating it out was to avoid bogging
> down the vast majority of threads which aren't debugged. If
> you think the extra overhead isn't worth worrying about then
> the hw-breakpoint info structure can be embedded.
yeah. This new facility is barely used, and such things should
always strive for 100% dumb simplicity. If the overhead of that
structure is ever a problem we can allocate it dynamically. (but
generally it's just not worth the pain)
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists