From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25707 invoked by alias); 25 Nov 2013 18:21:57 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 25692 invoked by uid 89); 25 Nov 2013 18:21:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Nov 2013 18:21:16 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAPIL8Y1014834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Nov 2013 13:21:08 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rAPIL5PX014504; Mon, 25 Nov 2013 13:21:06 -0500 Message-ID: <52939510.7000308@redhat.com> Date: Mon, 25 Nov 2013 18:21:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: lgustavo@codesourcery.com CC: "gdb@sourceware.org" , Tom Tromey , "Maciej W. Rozycki" Subject: Re: Unreliable BFD caching heuristic References: <528E454F.6060003@codesourcery.com> <528E49B8.8090409@redhat.com> <52938CB2.8080700@codesourcery.com> In-Reply-To: <52938CB2.8080700@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00097.txt.bz2 On 11/25/2013 05:45 PM, Luis Machado wrote: > We can't rely on the timestamp due to some filesystems having 1 second > or 2 seconds resolution. That doesn't seem enough. We can't rely on timestamps to be sure the files are the same, but we can assume that if the files have different timestamps, they're not the same. IOW, if we have some other fallback file comparison method that is more expensive, we only need to apply it if the timestamps match; if they don't match, we can assume the file is not the same. Sure, if the same file is accessed through different filesystems, we can end up thinking we had two handles for different files, but then all that's lost is we don't apply the bfd sharing optimization in that rare scenario. -- Pedro Alves