On 06/13/24 at 05:23pm, Zhaoyang Huang wrote: > On Thu, Jun 13, 2024 at 5:11 PM hailong liu <hailong.liu@xxxxxxxx> wrote: > > > > On Thu, 13. Jun 16:41, Baoquan He wrote: > > > On 06/12/24 at 01:27pm, Uladzislau Rezki wrote: > > > > On Wed, Jun 12, 2024 at 10:00:14AM +0800, Zhaoyang Huang wrote: > > > > > On Wed, Jun 12, 2024 at 2:16 AM Uladzislau Rezki <urezki@xxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > Sorry to bother you again. Are there any other comments or new patch > > > > > > > on this which block some test cases of ANDROID that only accept ACKed > > > > > > > one on its tree. > > > > > > > > > > > > > I have just returned from vacation. Give me some time to review your > > > > > > patch. Meanwhile, do you have a reproducer? So i would like to see how > > > > > > i can trigger an issue that is in question. > > > > > This bug arises from an system wide android test which has been > > > > > reported by many vendors. Keep mount/unmount an erofs partition is > > > > > supposed to be a simple reproducer. IMO, the logic defect is obvious > > > > > enough to be found by code review. > > > > > > > > > Baoquan, any objection about this v4? > > > > > > > > Your proposal about inserting a new vmap-block based on it belongs > > > > to, i.e. not per-this-cpu, should fix an issue. The problem is that > > > > such way does __not__ pre-load a current CPU what is not good. > > > > > > With my understand, when we start handling to insert vb to vbq->xa and > > > vbq->free, the vmap_area allocation has been done, it doesn't impact the > > > CPU preloading when adding it into which CPU's vbq->free, does it? > > > > > > Not sure if I miss anything about the CPU preloading. > > > > > > > > > > IIUC, if vb put by hashing funcation. and the following scenario may occur: Thanks for the details, it's truly a problem as you said. > > > > A kthread limit on CPU_x and continuously calls vm_map_ram() > > The 1 call vm_map_ram(): no vb in cpu_x->free, so > > CPU_0->vb > > CPU_1 > > ... > > CPU_x > > > > The 2 call vm_map_ram(): no vb in cpu_x->free, so > > CPU_0->vb > > CPU_1->vb > > ... > > CPU_x > Yes, this could make the per_cpu vbq meaningless and the VMALLOC area > be abnormally consumed(like 8KB in 4MB for each allocation) > > > > -- > > help you, help me, > > Hailong. >
