Searched refs:worst (Results 1 – 7 of 7) sorted by relevance
9 ; 16b * 16b = 372 states (worst case)10 ; 32b * 32b = 724 states (worst case)
506 # The worst case at the block level is a growth of the compressed data509 # The worst case internal to a compressed block is very hard to figure.510 # The worst case can at least be bounded by having one bit that represents517 # block adding an extra 32767 bytes (the worst case uncompressed block size)518 # is sufficient, to ensure that in the worst case the decompressed data for
1177 int no_way_out, int *worst) in __mc_scan_banks() argument1233 if (severity > *worst) { in __mc_scan_banks()1235 *worst = severity; in __mc_scan_banks()1345 int worst = 0; in do_machine_check() local1413 __mc_scan_banks(&m, regs, final, toclear, valid_banks, no_way_out, &worst); in do_machine_check()1425 no_way_out = worst >= MCE_PANIC_SEVERITY; in do_machine_check()1439 if (worst >= MCE_PANIC_SEVERITY && mca_cfg.tolerant < 3) { in do_machine_check()1445 if (worst != MCE_AR_SEVERITY && !kill_current_task) in do_machine_check()
239 each function was tested at about 400 points. Ideal worst-case results307 worst-case results which are better than the worst-case results given321 the worst accuracy which was found (in bits) and the approximate value326 instr arg range # tests 63.7 63.8 63.9 worst at arg
44 * I discovered several bugs. First and worst is that the kernel
284 | Note that both routines have been optimized (for the worst case) and
360 # quotient will be at worst 1 too large.