Messages in this thread |  | | Date | Wed, 2 Jan 2002 16:55:13 -0800 (PST) | | From | Davide Libenzi <> | | Subject | Re: [PATCH] scheduler fixups ... |
| |
On 3 Jan 2002, Peter Osterlund wrote:
> Davide Libenzi <davidel@xmailserver.org> writes: > > > On 2 Jan 2002, Peter Osterlund wrote: > > > > > Davide Libenzi <davidel@xmailserver.org> writes: > > > > > > > a still lower ts > > > > > > This also lowers the effectiveness of nice values. In 2.5.2-pre6, if I > > > run two cpu hogs at nice values 0 and 19 respectively, the niced task > > > will get approximately 20% cpu time (on x86 with HZ=100) and this > > > patch will give even more cpu time to the niced task. Isn't 20% too > > > much? > > > > The problem is that with HZ == 100 you don't have enough granularity to > > correctly scale down nice time slices. Shorter time slices helps the > > interactive feel that's why i'm pushing for this. > > OK, but even architectures with bigger HZ values will suffer. Isn't it > better to set MIN_NICE_TSLICE to a smaller value (such as 1000) and > fix the calculation in fill_tslice_map to make sure ts_table[i] is > always non-zero. The current formula will break anyway if > > HZ < 1000000 / MIN_NICE_TSLICE = 100, > > but maybe HZ >= 100 is true for all architectures?
Yep, but we can do something like :
static void fill_tslice_map(void) { int i;
for (i = 0; i < NICE_RANGE; i++) { ts_table[i] = ((MIN_NICE_TSLICE + ((MAX_NICE_TSLICE - MIN_NICE_TSLICE) / (NICE_RANGE - 1)) * i) * HZ) / 1000000; if (!ts_table[i]) ts_table[i] = 1; } }
- Davide
- 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/
|  |