On an AZURE system there is a "local" device that is useful as swap.
It is, I believe, faster than regular network based storage, but it is
ephemeral, and may go away during a shutdown.
It is in some machines a bit small so we'd like to add a bit more for
safety.
But we would like the ephemeral
ty in -current. High user priorities decay to (PUSER +
niceness) so the possibilities for priority inversion from this are
limited and it's mainly a latency bug.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, 4 Feb 2003, Kris Kennaway wrote:
> On Tue, Feb 04, 2003 at 09:54:23PM -0800, Steve Kargl wrote:
> > On Tue, Feb 04, 2003 at 09:38:18PM -0800, Kris Kennaway wrote:
> > > I just booted a kernel with SCHED_ULE. It looks like there's a pretty
> > > serious bug:
> > >
> > > PID USERNAME PRI
On Tue, Feb 04, 2003 at 09:54:23PM -0800, Steve Kargl wrote:
> On Tue, Feb 04, 2003 at 09:38:18PM -0800, Kris Kennaway wrote:
> > I just booted a kernel with SCHED_ULE. It looks like there's a pretty
> > serious bug:
> >
> > PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAN
On Tue, Feb 04, 2003 at 09:38:18PM -0800, Kris Kennaway wrote:
> I just booted a kernel with SCHED_ULE. It looks like there's a pretty
> serious bug:
>
> PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
> 573 dnetc139 20 1000K 804K RUN 1:29 85.94% 85.94% d
On Tue, Feb 04, 2003 at 09:38:18PM -0800, Kris Kennaway wrote:
> I just booted a kernel with SCHED_ULE. It looks like there's a pretty
> serious bug:
>
> PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
> 573 dnetc139 20 1000K 804K RUN 1:29 85.94% 85.94% d
I just booted a kernel with SCHED_ULE. It looks like there's a pretty
serious bug:
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
573 dnetc139 20 1000K 804K RUN 1:29 85.94% 85.94% dnetc
661 kris 960 2252K 1496K RUN 0:00 6.25% 6.25% to
> -Original Message-
> From: Doug White [SMTP:dwh...@resnet.uoregon.edu]
> Sent: Sunday, May 23, 1999 2:46 AM
> To: Doug Rabson
> Cc: FreeBSD current Mailing list
> Subject: Re: priorities
>
> On Fri, 21 May 1999, Doug Rabson wrote:
>
> If you
On Fri, 21 May 1999, Doug Rabson wrote:
> > It sounds like we can loads of haggling about the names there... The
> > last one is to take out the dependency on errno being greater than
> > zero.
>
> I would actually quite like to keep the possibility of returning an errno.
> It gives the possibili
<
said:
> How do you guarantuee that the errno is positive? Add an assert
> somewhere, like checking whether ENXIO >= PRIORITY_FAIL?
No, we simply define it to be so.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.edu | O Siem / T
On Fri, 21 May 1999, Bruce Evans wrote:
> >> >They just are positive and have always been positive :-)
> >> >
> >> >Changing that (making errnos negative) would break so much code I don't
> >> >even want to think about it.
> >>
> >> >From errno.h:
> >>
> >> #ifdef KERNEL
> >> /* pseudo-errors re
>> >They just are positive and have always been positive :-)
>> >
>> >Changing that (making errnos negative) would break so much code I don't
>> >even want to think about it.
>>
>> >From errno.h:
>>
>> #ifdef KERNEL
>> /* pseudo-errors returned inside kernel to modify return to process */
>> #def
On Fri, 21 May 1999, Bruce Evans wrote:
> >> How do you guarantuee that the errno is positive? Add an assert
> >> somewhere, like checking whether ENXIO >= PRIORITY_FAIL?
> >
> >They just are positive and have always been positive :-)
> >
> >Changing that (making errnos negative) would break so mu
>> How do you guarantuee that the errno is positive? Add an assert
>> somewhere, like checking whether ENXIO >= PRIORITY_FAIL?
>
>They just are positive and have always been positive :-)
>
>Changing that (making errnos negative) would break so much code I don't
>even want to think about it.
On Fri, 21 May 1999, Nick Hibma wrote:
> > > #define PRIORITY_FAIL-1
> > >
> > > It sounds like we can loads of haggling about the names there... The
> > > last one is to take out the dependency on errno being greater than
> > > zero.
> >
> > I would actually quite like to kee
> > #define PRIORITY_FAIL -1
> >
> > It sounds like we can loads of haggling about the names there... The
> > last one is to take out the dependency on errno being greater than
> > zero.
>
> I would actually quite like to keep the possibility of returning an errno.
> It gives
On Thu, 20 May 1999, Nick Hibma wrote:
>
> You set a 'low' priority for the ide match as -100. I suggest we use a
> much lower value for that: -1. With USB we have 15 levels already,
> spaced ten apart (welcome back BASIC :) makes 150.
>
> Has anyone come up with a decent set of levels yet,
You set a 'low' priority for the ide match as -100. I suggest we use a
much lower value for that: -1. With USB we have 15 levels already,
spaced ten apart (welcome back BASIC :) makes 150.
Has anyone come up with a decent set of levels yet, or is the best bet
still Mike's example (can;
#def
18 matches
Mail list logo
