From owner-freebsd-current@FreeBSD.ORG Thu Jul 7 23:45:51 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83E24106566B; Thu, 7 Jul 2011 23:45:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id E43B58FC13; Thu, 7 Jul 2011 23:45:50 +0000 (UTC) Received: by ywf7 with SMTP id 7so735936ywf.13 for ; Thu, 07 Jul 2011 16:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jVjQUkH04ea3unW0HU8dW+DNAZkXaeu98Yg+m86GVrI=; b=j1RDX9t90XgTjVsVVQ64nI2JStye4SQFMyrUo/EodkJWGXqnJ0hF35fhiQx+v4UH0L my4azAtkXNFgKAK0+ymeoRL3osl+BcCKKukj1+mEorhM8rNY3Gd9mzw8GqkuL6Ul6twM X0sS3t6NsWLo1tqhtzi4bav3DQ1XBsezOnHFY= MIME-Version: 1.0 Received: by 10.151.50.15 with SMTP id c15mr1509604ybk.285.1310082350186; Thu, 07 Jul 2011 16:45:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Thu, 7 Jul 2011 16:45:50 -0700 (PDT) In-Reply-To: References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> Date: Fri, 8 Jul 2011 07:45:50 +0800 X-Google-Sender-Auth: QiFqO3AlDiZ1icJvGKpMKp-le5o Message-ID: From: Adrian Chadd To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Steve Kargl , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 23:45:51 -0000 (OT, yes, but I'd like to take a stab at explaining "why" these things fall to the wayside..) On 7 July 2011 12:08, Arnaud Lacombe wrote: > What would be the point to even start looking at an issue? You guys > (by "you", I mean "official" committers on public list) don't care When someone who has an active interest takes ownership of the problem. > about people providing patches, might it be for trivial, obvious, > fixes. I'm not even talking about complex patches ... When you > eventually ends up providing a patch, you ends up being slammed a door > at by maintainers asserting their code is perfect, until logic and > user complaints prove them wrong. > > That said, this comment is off-topic, but I will certainly re-state > this next month when I'll be ping'ing trivial patches. The problem is that someone doesn't own the problem. If I commit someone's fix to the tree without really understanding what's going on, I take ownership of that change and any issues/breakages/changes that it creates. The people responsible for these areas are likely very busy with other things. It's not that they don't want to help! It's much more likely that they don't have the time. Trivial patches aren't always so trivial. You can change the behaviour of something subtle which works great for you and not for others. This is very likely what's going on with IO/CPU scheduling. It's a tricky area. A simple fix isn't always as simple. So if there's a diagnosed problem, with reproducable test cases and some patches which fix it, I suggest doing something like the following: * create a webpage, even if it's a wiki somewhere (even wiki.freebsd.org if you ask someone nicely) * dump all the information you can in there. Having stuff in emails is great - but it's only really helpful for tracking the 'flow' of a discussion. Having a summarised analysis of all of that on a webpage is much more helpful. * Add the patches there. * Encourage people who aren't in your immediate community to try them too - to try and find if your changes mess up other configurations somehow. * Be persistent trying to get your changes in. If you've done the background research, done some wide-spread testing and show you've not caused any obvious regressions, you're much more likely to get your changes in. With all of that done, you can likely find a committer who will help you get your fixes into the tree. Please just try not to interpret a lack of response as a lack of interest. There's only so much time in the day and committers tend to be a busy bunch, with day jobs that may in no way reflect their FreeBSD interests. Finally, if people do enough of the above and begin to take ownership of parts of the tree, you'll find someone will likely sponsor you for a commit bit. HTH, Adrian