On Mon, Jun 17, 2024 at 11:56 PM Huang, Ying <ying.huang@xxxxxxxxx> wrote: > > Chris Li <chrisl@xxxxxxxxxx> writes: > > > That is in general true with all kernel development regardless of > > using options or not. If there is a bug in my patch, I will need to > > debug and fix it or the patch might be reverted. > > > > I don't see that as a reason to take the option path or not. The > > option just means the user taking this option will need to understand > > the trade off and accept the defined behavior of that option. > > User configuration knobs are not forbidden for Linux kernel. But we are > more careful about them because they will introduce ABI which we need to > maintain forever. And they are hard to be used for users. Optimizing > automatically is generally the better solution. So, I suggest you to > think more about the automatically solution before diving into a new > option. I did, see my reply. Right now there are just no other options. > > >> > >> >> So, I prefer the transparent methods. Just like THP vs. hugetlbfs. > >> > > >> > Me too. I prefer transparent over reservation if it can achieve the > >> > same goal. Do we have a fully transparent method spec out? How to > >> > achieve fully transparent and also avoid fragmentation caused by mix > >> > order allocation/free? > >> > > >> > Keep in mind that we are still in the early stage of the mTHP swap > >> > development, I can have the reservation patch relatively easily. If > >> > you come up with a better transparent method patch which can achieve > >> > the same goal later, we can use it instead. > >> > >> Because we are still in the early stage, I think that we should try to > >> improve transparent solution firstly. Personally, what I don't like is > >> that we don't work on the transparent solution because we have the > >> reservation solution. > > > > Do you have a road map or the design for the transparent solution you can share? > > I am interested to know what is the short term step(e.g. a month) in > > this transparent solution you have in mind, so we can compare the > > different approaches. I can't reason much just by the name > > "transparent solution" itself. Need more technical details. > > > > Right now we have a clear usage case we want to support, the swap > > in/out mTHP with bigger zsmalloc buffers. We can start with the > > limited usage case first then move to more general ones. > > TBH, This is what I don't like. It appears that you refuse to think > about the transparent (or automatic) solution. Actually, that is not true, you make the wrong assumption about what I have considered. I want to find out what you have in mind to compare the near term solutions. In my recent LSF slide I already list 3 options to address this fragmentation problem.
