Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 9 Apr 2001 19:28:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 9 Apr 2001 19:28:40 -0400 Received: from nrg.org ([216.101.165.106]:53264 "EHLO nrg.org") by vger.kernel.org with ESMTP id ; Mon, 9 Apr 2001 19:28:37 -0400 Date: Mon, 9 Apr 2001 16:28:27 -0700 (PDT) From: Nigel Gamble Reply-To: nigel@nrg.org To: bsuparna@in.ibm.com cc: paul.mckenney@us.ibm.com, lse-tech@lists.sourceforge.net, linux-kernel@vger.kernel.org, ak@suse.de, dipankar.sarma@in.ibm.com Subject: Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel In-Reply-To: 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 Mon, 9 Apr 2001 bsuparna@in.ibm.com wrote: > As you've observed, with the approach of waiting for all pre-empted tasks > to synchronize, the possibility of a task staying pre-empted for a long > time could affect the latency of an update/synchonize (though its hard for > me to judge how likely that is). It's very unlikely on a system that doesn't already have problems with CPU starvation because of runaway real-time tasks or interrupt handlers. First, preemption is a comparitively rare event with a mostly timesharing load, typically from 1% to 10% of all context switches. Second, the scheduler should not penalize the preempted task for being preempted, so that it should usually get to continue running as soon as the preempting task is descheduled, which is at most one timeslice for timesharing tasks. Nigel Gamble nigel@nrg.org Mountain View, CA, USA. http://www.nrg.org/ MontaVista Software nigel@mvista.com - 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/