Re: [PATCH] block: fix q->max_segment_size checking in blk_recalc_rq_segments about VMERGE

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Mikulas Patocka
Date: Tuesday, July 15, 2008 - 2:50 pm

> > > Yes, but it's gains very little ... architectures that don't want it can

So show a specific device where the virtual merge accounting is useful.

(1) The device that is often used in alpha or pa-risc environments --- 
because the accounting is not used on other archs.

(2) The device that is performance-sensitive --- not something outdated or 
unusual.

(3) And the device that has limited sg-list size, so that generic I/O 
requests made by the kernel hit this limit. (if the sg-list is so big that 
nr_phys_segments of most requests fits into it, you don't need to count 
nr_hw_segments --- because nr_hw_segments < nr_phys_segments and 
nr_phys_segments already fits).

[ the device that traverses its sg-list slowly doesn't fall into category 
(3), beacuse virtual merging would happen with or without nr_hw_segments 
accounting ]

Mikulas
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH] block: fix q->max_segment_size checking in blk ..., Mikulas Patocka, (Tue Jul 15, 2:50 pm)