Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 3 Feb 2002 20:23:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 3 Feb 2002 20:23:28 -0500 Received: from squeaker.ratbox.org ([63.216.218.7]:34820 "EHLO squeaker.ratbox.org") by vger.kernel.org with ESMTP id ; Sun, 3 Feb 2002 20:23:18 -0500 Date: Sun, 3 Feb 2002 20:30:11 -0500 (EST) From: Aaron Sethman To: Dan Kegel Cc: Kev , Arjen Wolfs , , , "linux-kernel@vger.kernel.org" Subject: Re: [Coder-Com] Re: PROBLEM: high system usage / poor SMPnetwork performance In-Reply-To: <3C5DE0D2.77DDE891@kegel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 3 Feb 2002, Dan Kegel wrote: > I'd like to know how it disagrees. > I believe rtsig requires you to tweak your I/O code in three ways: > 1. you need to pick a realtime signal number to use for an event queue Did that. > 2. you need to wrap your read()/write() calls on the socket with code > that notices EWOULDBLOCK This is perhaps the part we it disagrees with our code. I will investigate this part. The way we normally do things is have callbacks per fd, that get called when our event occurs doing the read, or, write directly. We do check for the EWOULDBLOCK stuff and re-register the event. The thing we do not currently do is, attempt to read or write unless we've received notification first. This is what I am assuming is breaking it. > 3. you need to fall back to poll() on signal queue overflow. Did that part too. Regards, Aaron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/