-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preemption Support #674
Preemption Support #674
Conversation
I just spotted these in dmesg: [ 1283.525520] BUG: using smp_processor_id() in preemptible [00000000] code: txg_sync/3247 I am testing a fix for it. I will add it to this pull request after I have something that works. |
I accidentally clicked the close "Close & comment" button earlier.Anyway, I revised the txg_hold_open patch and also have a patch for fm_ena_generate. This should resolve the known issues in kernel preemption support. |
It looks like we should be using get_cpu() and put_cpu() in situations where we use smp_processor_id(). I will rework these patches to use them when I find time. |
@ryao, could you please rebase on top of 0.6.0-rc9 ? Now it gives conflicts at merging. |
@ierdnah, I have updated my patches, but I omitted changes to the ./configure script. People will need to run ./autogen.sh to regenerate the ./configure script until this is committed by Brian. |
@behlendorf could you please pull this in zfs ? This fix would give us a broader range of testers (those who have preemptible kernels). |
@ryao The rebase it's not ok, in your repo the last commit before your preempt patches is from 19 of april. If I try to merge your branch with 0.6.0-rc9 it gives conflicts at file config/kernel.m4. |
@ierdnah Sorry about that. My tree should now be in sync. |
Thanks, it's ok now. I'm running zfs with a preemptible kernel. |
+1 for merging preempt "alpha" support, testers will come. |
I started working on this after @kylef demonstrated to me with ryao/spl@7214cf4 that making this work was easier than I thought it would be. I want to finish this ASAP, but my time is very limited. I would be more than happy if a third person would volunteer to finish this work. Otherwise, it will remain in my to do list. My issue list for this is that #757 should be examined (as full preemption in theory would only make that issue more likely) and get_cpu()/put_cpu() should be used. I believe Brian mentioned something about the SPL in another issue, although I am having trouble finding it. @behlendorf Would you outline your concerns with regard to these patches? That way anyone interested in finishing this before I have a chance could do so. On that note, a lightly patched version of 0.6.0-rc9 has entered Gentoo's testing tree. This effectively transfers control of what runs on users' systems from the ZFSOnLinux project to myself. Users have the option to override that, but few do. If Brian decides to merge these patches into the ZFSOnlinux project for wider testing, I will pull them into Gentoo. Otherwise, I will continue to wait until concerns blocking inclusion have been resolved, despite using these on my own system. |
zfs_range_lock() is used in zvols, and previously, it could deadlock due to an allocation using KM_SLEEP. We avoid this by moving responsibility the memory allocation from zfs_range_lock() to the caller. This enables us to avoid such deadlocks and use stack allocations, which are more efficient and prevents deadlocks. The contexts in which stack allocations are done do not appear to be stack heavy, so we do not risk overflowing the stack from doing this. Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu> Conflicts: module/zfs/zvol.c
Is there any unknown reason that these preemption support isn´t commited into ZOL? It may be not finished as the state of issue openzfs/spl#98 may indicate ... but it will be nice if there will be preemption support soon. |
It would be nice to have this done. But it's waiting on some minor reworking of openzfs/spl#98 and I still need to sit down and carefully review the needed zfs changes. |
Issue #546 was something of a distraction from working on that. Anyway, I think I will work on openzfs/spl#98 as soon as openzfs/spl#147 is out of the way. On that note, I need to remove ryao/zfs@513ad2a from this pull request. Further testing showed that the stack size was too small to accommodate it in all situations. |
@prakash-surya has taken the time to improve upon these patches in pull request #891. This pull request is now obsolete. |
Add missing helper function cv_timedwait_io(), it should be used when waiting on IO with a specified timeout. Reviewed-by: Tim Chase <tim@chase2k.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#674
Revert "zfs list: Allow more fields in ZFS_ITER_SIMPLE mode"
This reverts an earlier patch that causes a ./configure failure if CONFIG_PREEMPT and modifies txg_hold_open to support preemptable kernels. It depends on a pull request to zfsonlinux/spl and it closes issue #83.