Re: bdflush/rpciod high CPU utilization, profile does not make sense

su den 24.04.2005 Klokka 09:15 (+0200) skreiv Jakob Oestergaard:
> Performance on SMP NFS client:
>          File   Block  Num  Seq Read    Rand Read   Seq Write  Rand Write
>   Dir    Size   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
> ------- ------ ------- --- ----------- ----------- ----------- -----------
>    .     2000   4096    1  47.53 80.0% 5.013 2.79% 22.34 32.2% 6.510 14.9%
>    .     2000   4096    2  45.29 78.6% 8.068 5.44% 24.53 34.1% 7.042 14.9%
>    .     2000   4096    4  45.38 78.0% 11.02 7.95% 25.13 35.1% 7.525 18.0%
> 
> Performance on UP NFS client:
>          File   Block  Num  Seq Read    Rand Read   Seq Write  Rand Write
>   Dir    Size   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
> ------- ------ ------- --- ----------- ----------- ----------- -----------
>    .     2000   4096    1  57.11 54.7% 69.60 24.9% 35.09 14.2% 6.656 19.1%
>    .     2000   4096    2  60.11 58.8% 70.99 30.8% 33.82 14.1% 7.283 25.1%
>    .     2000   4096    4  67.89 59.8% 42.10 19.1% 29.86 12.7% 7.850 26.4%
> 
> So, by booting the NFS client in uniprocessor mode, I got a 50% write
> performance boost, 20% read perforamance boost, and the tests use about
> half the CPU time.
> 
> Isn't this a little disturbing?  :)

Actually, the most telling difference here is with the random read rates
which shows up to 1000% difference. I seriously doubt that has much to
do with lock contention (given that the sequential reads show 20% as you
said).

Could you once again have a look at the retransmission rates (both UDP
and TCP), comparing the SMP and UP cases?

Cheers,
  Trond
-- 
Trond Myklebust <[email protected]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

---

• References:
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Jakob Oestergaard <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Trond Myklebust <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Jakob Oestergaard <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Trond Myklebust <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Jakob Oestergaard <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Greg Banks <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Jakob Oestergaard <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Jakob Oestergaard <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Trond Myklebust <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Jakob Oestergaard <[email protected]>
  • Re: bdflush/rpciod high CPU utilization, profile does not make sense
    • From: Jakob Oestergaard <[email protected]>

• Prev by Date: Two questions related with FAT filesystem and block device layer.
• Next by Date: Re: Git-commits mailing list feed.
• Previous by thread: Re: bdflush/rpciod high CPU utilization, profile does not make sense
• Next by thread: return value of ptep_get_and_clear
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]