From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15623 invoked by alias); 26 Aug 2009 16:29:53 -0000 Received: (qmail 15612 invoked by uid 22791); 26 Aug 2009 16:29:52 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Aug 2009 16:29:46 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n7QGTgAf020353 for ; Wed, 26 Aug 2009 17:29:43 +0100 Received: from pxi33 (pxi33.prod.google.com [10.243.27.33]) by zps37.corp.google.com with ESMTP id n7QGTeQS028706 for ; Wed, 26 Aug 2009 09:29:40 -0700 Received: by pxi33 with SMTP id 33so237743pxi.11 for ; Wed, 26 Aug 2009 09:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.20.9 with SMTP id x9mr3624633rvi.201.1251304180093; Wed, 26 Aug 2009 09:29:40 -0700 (PDT) In-Reply-To: <200908251944.45977.pedro@codesourcery.com> References: <7e6c8d660907081308r13bff580rdcf4822c77df8403@mail.gmail.com> <200908251944.45977.pedro@codesourcery.com> Date: Wed, 26 Aug 2009 16:36:00 -0000 Message-ID: Subject: Re: [RFA] Use data cache for stack accesses From: Doug Evans To: Pedro Alves Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-08/txt/msg00448.txt.bz2 On Tue, Aug 25, 2009 at 11:44 AM, Pedro Alves wrote: > On Tuesday 25 August 2009 01:48:30, Doug Evans wrote: >> On Thu, Aug 20, 2009 at 11:00 PM, Doug Evans wrote: >> > On Wed, Jul 8, 2009 at 1:46 PM, Pedro Alves wr= ote: >> >> On Wednesday 08 July 2009 21:08:00, Jacob Potter write: > >> >> What if we do this within dcache itself, similarly >> >> to get_thread_regcache? =A0That would be probably in [dcache_xfer_par= tial]. >> > >> > It seems that given that we can temporarily change inferiors without >> > giving subsystems notice of the change, and given vfork, then we need >> > to have intelligence in dcache to handle this (and then it's not clear >> > if we should keep one dcache per inferior). >> > >> > How about having memory_xfer_partial notify dcache of every >> > write/read, and then dcache could keep just one copy of the cache and >> > flush it appropriately? > >> Something like this? > > Eh, that's exactly what I meant by 'similarly to get_thread_regcache'. > (Ulrich rewritten it since somewhat to keep more than one more than > one regcache live at once). > > A few small nits: Please fix up a few missing > double-space-after-period instances, and here, > >> + =A0if (inf >> + =A0 =A0 =A0&& readbuf =3D=3D NULL > > both inf and readbuf are pointers, so please either make both > subpredicates compare with NULL or neither. =A0Hmm, actually, I'm not > sure =A0why you still need to check the inferior for nullness > in this version? It wasn't clear to me whether TRTTD was check inf for NULL either, but the code can only be used if there is an inferior so I left it in. > I think that the cache should be flushed with > "set stack-cache off" -> "set stack-cache on", you never > know what happened between these two commands, so you end up > with a stale cache. Righto. > If write_memory|stack tries to write to [foo,bar), and that > operation fails for some reason somewhere between foo and bar, I > think that the cache between somewhere and bar shouldn't be > updated with the new values. =A0Is it? Indeed. I recall looking at this but I'll go back and check. > I worry about new stale cache issues in non-stop mode. > [...] > It appears that (at least in non-stop or if any thread is running) > the cache should only be live for the duration of an "high level > operation" --- that is, for a "backtrace", or a "print", etc. > Did you consider this? It wasn't clear how to handle non-stop/etc. mode so I left that for the next iteration. If only having the data live across a high level operation works for you, it works for me. > Did you post number showing off the improvements from > having the cache on? =A0E.g., when doing foo, with cache off, > I get NNN memory reads, while with cache off, we get only > nnn reads. =A0I'd be curious to have some backing behind > "This improves remote performance significantly". For a typical gdb/gdbserver connection here a backtrace of 256 levels went from 48 seconds (average over 6 tries) to 4 seconds (average over 6 tries).