>From peter@xxxxxxxxxxxxxxxxxx Thu Mar 12 11:30:55 2015
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:cc:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=aucBi/TSwLpLV0OB76kkSr0wIQwLAWMFSMx9pC0d8Vc=;
b=DJ0d6hCs+QmCl0GOnY161MMkh6elZHxz+rytQjDVkY56Qb7z73MgqNFwRD3q4FxtjH
HaR75Z+1YsjLjSx8jBjRU0QyEezU1Qj8BokUI7q7ctu1ZGUXnQgtVBdk8HSAEuKpmVnp
jAeCv7h9AnoqUh6Ip2wGhdrwsdvC5yCyRJkZa56MVSpruStQyMFWCJlYHPJkyYuaUwsl
MTjCOlB4Y+Izooqe5fDFCJD6vnjkRYdm9H51PJmLUfe0dyFfruq/roJ2RUdzy9DGTn7E
Dsz/f8W9TW+uk36XgoD9BjEMP/qyIMknP9mkS9NX6HeZ1o3eLzMK2LSIby5rt3O7e24I
wnQw==
X-Gm-Message-State: ALoCoQkHbbKnaZ6qlfnul6jc1qrQzUntI+q6KJ9CJQ/6WcNYIw9uuopKirHNUl6DVchxnxTWSwaM
X-Received: by 10.140.152.72 with SMTP id 69mr53844363qhy.53.1426159853642;
Thu, 12 Mar 2015 04:30:53 -0700 (PDT)
Date: Thu, 12 Mar 2015 07:30:51 -0400
From: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: George Spelvin <linux@xxxxxxxxxxx>, prasad.koya@xxxxxxxxx
CC: gregkh@xxxxxxxxxxxxxxxxxxx, linux-serial@xxxxxxxxxxxxxxx,
prasad@xxxxxxxxxx
Subject: Re: Is this a bug in the current serial8250_rx_chars()?
References: <20150310224938.4668.qmail@xxxxxxxxxxxxxx>
In-Reply-To: <20150310224938.4668.qmail@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
On 03/10/2015 06:49 PM, George Spelvin wrote:
> By the way, there's also a performance bug in tty_insert_flip_char.
> If (tb->flags & TTYB_NORMAL), then tb->used is allowed to go up
> to 2*tb->size, as the __tty_buffer_request_room code makes clear.
> But tty_insert_flip_char() doesn't know that and will take the slow path
> for the second half of every buffer.
> In practice, this doesn't happen because drivers that use
> tty_insert_flip_char() won't have compressed buffers (ie., TTYB_NORMAL).
> That's because tty_insert_flip_string_flags() will always get the
> uncompressed buffer flavor.
Ah, thank you! I had missed the fact that the "flag" argument to
__tty_buffer_request_room is 0 = uncompressed, TTYB_NORMAL = 1 = compressed,
so the call chain
tty_insert_flip_char
-> tty_insert_flip_string_flags
-> tty_buffer_request_room
-> __tty_buffer_request_room(port, size, 0)
always allocates an uncompressed buffer.
I had it mixed up with the "flags" parameter which is 0 = TTY_NORMAL =
compressed is permissible.
> That's to avoid buffer type hysteresis on a dirty line.
I was thinking of tweaking it so that a compressed buffer can be converted
in-place to an uncompressed buffer as long as it's less than half full,
i.e. b->used < b->size.
If it's done properly (barrier between filling the flag buffer and
clearing the TTYB_NORMAL flag), then receive_buf can remain lockless.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
