From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15942 invoked by alias); 5 Dec 2013 14:08:53 -0000 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 Received: (qmail 15932 invoked by uid 89); 5 Dec 2013 14:08:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.5 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Dec 2013 14:08:51 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VoZbY-0006Yy-5q from Yao_Qi@mentor.com ; Thu, 05 Dec 2013 06:08:36 -0800 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Dec 2013 06:08:35 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.2.247.3; Thu, 5 Dec 2013 06:08:35 -0800 Message-ID: <52A0888B.5000309@codesourcery.com> Date: Thu, 05 Dec 2013 14:08:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pedro Alves CC: Mark Kettenis , Subject: Re: [PATCH 2/3] skip_prolgoue (amd64) References: <1385735051-27558-1-git-send-email-yao@codesourcery.com> <1385735051-27558-3-git-send-email-yao@codesourcery.com> <201311291436.rATEaZ5Z030292@glazunov.sibelius.xs4all.nl> <201311291605.rATG5XVb030184@glazunov.sibelius.xs4all.nl> <52994E79.4000004@codesourcery.com> <5299B9D0.2020304@redhat.com> <529C37A2.9000207@codesourcery.com> <529E9462.9010001@codesourcery.com> <529F1B1F.2040606@redhat.com> <529FD4B9.10008@codesourcery.com> <52A06AC1.1030209@redhat.com> In-Reply-To: <52A06AC1.1030209@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00182.txt.bz2 On 12/05/2013 08:00 PM, Pedro Alves wrote: > I think we can. My view here is that handling an event > is a quick and short lived operation. GDB bursts a few reads > in sequence, and then moves on to the next event. In that > scenario, you get as much stale results with or without a cache. I disagree. Results may be staled with cache, but results may be different, not staled, without cache. They are different because they are red on different times, but all of them are valid. It is a snapshot of a piece of memory on a certain moment. > IOW, even without the cache, running threads can change memory as > GDB reads it, and so the chances of hitting stale data with or > without a cache are practically the same. OTOH, distinct target > events (and commands, etc.) can trigger quite apart (time-wise), > and that break the odd balance -- not flushing the cache > between events increases the changes of hitting stale data, I suspect you meant "chances" instead of "changes". > compared to not having a cache. Flushing the cache decreases likelihood of getting staled data, but can't completely remove it. I am fine to use cache in non-stop mode, as it helps performance, so we have to compromise. > >> >Beside the predicate "is any thread running", another is "no thread is >> >resumed since last flushing". Cache should be flushed when either is >> >true. > Not sure I understood that. I meant, even "none of threads is running now", we may have to flush cache if "they were resumed" (and all stopped now). -- Yao (齐尧)