From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26675 invoked by alias); 13 Nov 2019 20:36:10 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 26665 invoked by uid 89); 13 Nov 2019 20:36:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_JMF_BL,SPF_PASS autolearn=no version=3.3.1 spammy=our X-HELO: mail-oi1-f193.google.com Received: from mail-oi1-f193.google.com (HELO mail-oi1-f193.google.com) (209.85.167.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Nov 2019 20:36:08 +0000 Received: by mail-oi1-f193.google.com with SMTP id y194so3088559oie.4 for ; Wed, 13 Nov 2019 12:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KRnsk1EoJ0P6UQRB41ctBojRapWQ/dtjC9LV+5QniY4=; b=BMUr1Wm8c9n9ZXZl7EGGl2fnpZdPeGod0/5xJ9VyxBeuf6b4QMCGLER/qu0tjQ3xwy ziivJbt/QZzeL3sJ9twaZck0WeEY2aZSYcFM/WDsS1Ssj6P5ZSbUX6XNYlN4tPFRo3W8 JqIaZAfpks/uz4HC7PKNuxCUJDipSDW0P7ddM3hWx5DOJgGSHhBUKUjsxS4q9OVJWeE8 lrl9GLl8Z5tVWyXs9H6hZVTC50neVhC3ZMowrPGdpA38ZU4fP8qw4s9NdB8b9gCOPr1u /SXY7UyHc/CcDE0co7ba9DkTcoRMxj5HCcP1EQrFIeRL60rRGVQhJH6JRN9gC+tMCyrF bo+g== MIME-Version: 1.0 From: Bastien Bouclet Date: Wed, 13 Nov 2019 20:36:00 -0000 Message-ID: Subject: Re: [PATCH] newlib: fix fseek optimization with SEEK_CUR To: newlib@sourceware.org Content-Type: multipart/mixed; boundary="0000000000006f0eec05974050c6" X-SW-Source: 2019/txt/msg00638.txt.bz2 --0000000000006f0eec05974050c6 Content-Type: text/plain; charset="UTF-8" Content-length: 1218 Hi Corinna, Thank you for your answer. > I checked this against upstream BSD versions. OpenBSD and NetBSD > operate like our code, including the flush, while FreeBSD uses its > internal ftello and never flushed since the repository import back in > 1994. One difference I've noticed is that fflush does not invalidate the stream read buffer in the BSD versions of libc. In newlib this was introduced in commit a8ef755c2776b8da4ea386360c1df74ce268c165. Which is probably why OpenBSD and NetBSD can call fflush in fseek with SEEK_CUR. > Can we be sure this works as desired on append streams as well? Regarding the append streams, it's worth noting there is another call to fflush at the beginning of fseek in that case. I've written a small test program to verify they did not regress in simple cases. > Also, given that this is changing very basic code, nobody is unaffected. I would like to see the performance issue fixed one way or another. The systems I target do not have a page cache, the extra reads have a noticeable impact on user experience. Another other option could be having a compile time option for disabling the code in fflush that forces a disk access on the next read. Regards, Bastien --0000000000006f0eec05974050c6 Content-Type: text/x-csrc; charset="US-ASCII"; name="stdio-append.c" Content-Disposition: attachment; filename="stdio-append.c" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_k2xqihbp0 Content-length: 2115 I2luY2x1ZGUgPGVycm5vLmg+CiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVk ZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxzdHJpbmcuaD4KCmludCBtYWluKCkg ewoJRklMRSAqZnAgPSBmb3BlbigidGVzdC50eHQiLCAiYSsiKTsKCWlmIChm cCA9PSBOVUxMKSB7CgkJcHV0cygiZmFpbGVkIHRvIG9wZW4gdGVzdCBmaWxl IGluIGFwcGVuZCBtb2RlIik7CgkJZXhpdCgxKTsKCX0KCglzaXplX3Qgd3Jp dHRlbiA9IGZ3cml0ZSgiMTIzNDU2Nzg5MCIsIDEwLCAxLCBmcCk7CglpZiAo d3JpdHRlbiAhPSAxKSB7CgkJcHV0cygiZmFpbGVkIHRvIHdyaXRlIik7CgkJ ZXhpdCgxKTsKCX0KCglpbnQgcmV0ID0gZnNlZWsoZnAsIC04LCBTRUVLX0NV Uik7CglpZiAocmV0ID09IC0xKSB7CgkJcHV0cygiZmFpbGVkIHRvIHNlZWsi KTsKCQlleGl0KDEpOwoJfQoKCWNoYXIgcmVhZF9idWZbMTAwXTsKCW1lbXNl dChyZWFkX2J1ZiwgMCwgc2l6ZW9mKHJlYWRfYnVmKSk7CgoJc2l6ZV90IHJl YWQgPSBmcmVhZChyZWFkX2J1ZiwgMiwgMSwgZnApOwoJaWYgKHJlYWQgIT0g MSkgewoJCXByaW50ZigiZmFpbGVkIHRvIHJlYWQgJWRcbiIsIGVycm5vKTsK CQlleGl0KDEpOwoJfQoKCWlmIChzdHJjbXAocmVhZF9idWYsICIzNCIpICE9 IDApIHsKCQlwcmludGYoInVuZXhwZWN0ZWQgcmVhZCB2YWx1ZSAlc1xuIiwg cmVhZF9idWYpOwoJCWV4aXQoMSk7Cgl9CgoJcmV0ID0gdW5nZXRjKCdhJywg ZnApOwoJaWYgKHJldCAhPSAnYScpIHsKCQlwdXRzKCJmYWlsZWQgdG8gdW5n ZXRjIik7CgkJZXhpdCgxKTsKCX0KCglyZXQgPSBmc2VlayhmcCwgMywgU0VF S19DVVIpOwoJaWYgKHJldCA9PSAtMSkgewoJCXB1dHMoImZhaWxlZCB0byBz ZWVrIik7CgkJZXhpdCgxKTsKCX0KCglyZWFkID0gZnJlYWQocmVhZF9idWYs IDIsIDEsIGZwKTsKCWlmIChyZWFkICE9IDEpIHsKCQlwcmludGYoImZhaWxl ZCB0byByZWFkICVkXG4iLCBlcnJubyk7CgkJZXhpdCgxKTsKCX0KCglpZiAo c3RyY21wKHJlYWRfYnVmLCAiNzgiKSAhPSAwKSB7CgkJcHJpbnRmKCJ1bmV4 cGVjdGVkIHJlYWQgdmFsdWUgJXNcbiIsIHJlYWRfYnVmKTsKCQlleGl0KDEp OwoJfQoKCXdyaXR0ZW4gPSBmd3JpdGUoIjA5ODc2NTQzMjEiLCAxMCwgMSwg ZnApOwoJaWYgKHdyaXR0ZW4gIT0gMSkgewoJCXB1dHMoImZhaWxlZCB0byB3 cml0ZSIpOwoJCWV4aXQoMSk7Cgl9CgoJcmV0ID0gZnNlZWsoZnAsIC0yMCwg U0VFS19DVVIpOwoJaWYgKHJldCA9PSAtMSkgewoJCXB1dHMoImZhaWxlZCB0 byBzZWVrIik7CgkJZXhpdCgxKTsKCX0KCglyZWFkID0gZnJlYWQocmVhZF9i dWYsIDIwLCAxLCBmcCk7CglpZiAocmVhZCAhPSAxKSB7CgkJcHJpbnRmKCJm YWlsZWQgdG8gcmVhZCAlZFxuIiwgZXJybm8pOwoJCWV4aXQoMSk7Cgl9CgoJ aWYgKHN0cmNtcChyZWFkX2J1ZiwgIjEyMzQ1Njc4OTAwOTg3NjU0MzIxIikg IT0gMCkgewoJCXByaW50ZigidW5leHBlY3RlZCByZWFkIHZhbHVlICVzXG4i LCByZWFkX2J1Zik7CgkJZXhpdCgxKTsKCX0KCglmY2xvc2UoZnApOwoKCXB1 dHMoInN1Y2Nlc3MiKTsKCglyZXR1cm4gMDsKfQo= --0000000000006f0eec05974050c6--