Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755956AbdDMI6R (ORCPT ); Thu, 13 Apr 2017 04:58:17 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:38745 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750773AbdDMI6N (ORCPT ); Thu, 13 Apr 2017 04:58:13 -0400 Subject: Re: [PATCH 2/6] locking: Introduce range reader/writer lock To: Jan Kara References: <20170406084620.22700-1-dave@stgolabs.net> <20170406084620.22700-3-dave@stgolabs.net> <2a5c78b9-23ac-3b81-71ee-6a88b965f859@linux.vnet.ibm.com> <20170406165039.GA30318@linux-80c1.suse> <20170413083817.GC21025@quack2.suse.cz> Cc: Davidlohr Bueso , mingo@kernel.org, peterz@infradead.org, akpm@linux-foundation.org, kirill.shutemov@linux.intel.com, mhocko@suse.com, mgorman@techsingularity.net, linux-kernel@vger.kernel.org, Davidlohr Bueso From: Laurent Dufour Date: Thu, 13 Apr 2017 10:58:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170413083817.GC21025@quack2.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17041308-0040-0000-0000-00000386438D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041308-0041-0000-0000-00001FB03639 Message-Id: <19907583-178e-94a2-4297-52583cf285fb@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-13_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704130074 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 950 Lines: 23 On 13/04/2017 10:38, Jan Kara wrote: > On Thu 13-04-17 10:07:48, Laurent Dufour wrote: >> On 06/04/2017 18:50, Davidlohr Bueso wrote: >>> On Thu, 06 Apr 2017, Laurent Dufour wrote: >>> >>>> How is 'seqnum' wrapping handled here ? >>>> I'd rather see something like time_before() here, isn't it ? >>> >>> Its a 64bit counter, no overflows. >> >> I should have miss something, what prevents this 64bit counter to not >> overflow ? >> At some point of time, this counter could reach ~0UL and then 0UL, which >> is breaking this check. > > Count for yourself how long would it take for the counter to overflow if we > incremented it say every nanosecond? I do agree that this will take time, but systems become larger and having 200 threads hitting a lock like the mmap_sem every nanoseconds, it will increment faster (still need about 3 years)... if there are 1000 threads, less than 1 year to overflow this counter... This is not for today, I agree.