Hi,
On 5/11/23 4:47 AM, Steven Whitehouse wrote:
Hi,
This repeated kmalloc -> kfree -> kmalloc -> kfree is a waste of
time:
It is a waste of time. However, if the clones are kept around for lots
of rgrps, then that is a waste of space. The question is really what
the correct balance is.
Can we not solve the problem at source and prevent the large number of
lock transitions referred to above? If not then it might be a good plan
to document why that is the case,
Steve.
I do believe from a performance perspective, we might benefit just as
much (if not more) by, for example, using the LM_FLAG_ANY flag when
acquiring rgrp glocks in SH mode such as gfs2_check_blk_type.
That way if the lock is already in EX, we can just use it rather than
demote and promote it. There may be other places in the code where we
can do the same.
From a correctness perspective, one of my concerns is:
The go_inval() code is only run when transitioning to UN or DF, so
transitions from EX to SH and back won't call go_inval. They always call
go_sync, but rgrp_go_sync code exits (and avoids the whole bitmap issue)
unless the glock is GLF_DIRTY. It just seems fraught with pitfalls. But
still, it seems to work properly.
I had a meeting with Andreas this morning and we decided that since it
seems to work, "if it's not broken, don't fix it." So for now, I retract
the patch and we can readdress the issue if we find problems related to it.
Regards,
Bob Peterson
