Patch from Alessandro Premoli:

First, the problem: you cannot calculate sgv_max_local_order and 
sgv_max_trans_order by excess and then compare them with 
get_order(size). The maximum number of local (SG + trans) entries may be 
112 (like in amd64 case) and you bzero 128 sg_entries for every 
allocation request between 65 and 128 pages because the order is the 
same. This is the reason why single transfers of (70 * PAGE_SIZE) = 
~285k or more fail on amd64. On i386 the limit is higher, since you can 
shrink more records in one page, and so it's very difficult to reach.

Now, the solution: I created a patch, which consists in decreasing
sgv_max_local_order and sgv_max_trans_order by 1.


git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@140 d57e44dd-8a1f-0410-8b47-8ef2f437770f
This commit is contained in:
Vladislav Bolkhovitin
2007-07-02 11:36:22 +00:00
parent 772e541dd6
commit 3ab4521950
+2 -2
View File
@@ -723,11 +723,11 @@ int scst_sgv_pools_init(struct scst_sgv_pools *pools)
sgv_max_local_order = get_order(
((((PAGE_SIZE - sizeof(struct sgv_pool_obj)) /
(sizeof(struct trans_tbl_ent) + sizeof(struct scatterlist))) *
PAGE_SIZE) & PAGE_MASK));
PAGE_SIZE) & PAGE_MASK)) - 1;
sgv_max_trans_order = get_order(
((((PAGE_SIZE - sizeof(struct sgv_pool_obj)) /
(sizeof(struct trans_tbl_ent))) * PAGE_SIZE) & PAGE_MASK));
(sizeof(struct trans_tbl_ent))) * PAGE_SIZE) & PAGE_MASK)) - 1;
TRACE_MEM("sgv_max_local_order %d, sgv_max_trans_order %d",
sgv_max_local_order, sgv_max_trans_order);