This, and the rest of the series, look good. Feel free to add a Reviewed-by.
Thanks, Neil.
On 5/20/18, 11:39 PM, "lustre-devel on behalf of NeilBrown"
wrote:
libcfs allows other modules to register handlers for ioctls.
The implementation it uses for this is nearly identical to a
James,
If I understand correctly, you're saying you want to be able to build without
debug support...? I'm not convinced that building a client without debug
support is interesting or useful. In fact, I think it would be harmful, and we
shouldn't open up the possibility - this is switchable d
Lustre networking driver. (Or so I was taught)
Regards,
Patrick
From: lustre-devel on behalf of
NeilBrown
Sent: Monday, February 19, 2018 8:23:37 PM
To: Oleg Drokin; James Simmons; Andreas Dilger; Greg Kroah-Hartman
Cc: lkml; lustre
Subject: [lustre-
With the fix from yesterday, these look good. Thanks, Neil.
Reviewed-by: Patrick Farrell
- Patrick
On 2/12/18, 5:52 PM, "lustre-devel on behalf of NeilBrown"
wrote:
These macros are no longer used, so they can
be removed.
Reviewed-by: James Simmons
Sig
Neil,
I didn't get anything after 8/19 in this series. Is this just me? (I'd keep
waiting, except I also found a few things in this patch.)
Minor:
The line XXX ALLOCATE is out of date and could go. (It refers to a mix of
things you eliminated and things that were already gone.)
Less minor:
It's worth noting that the change from -EINTR to -ERESTARTSYS will modify the
behavior of userspace slightly. Specifically, when a signal handler is setup
with retry set (SA_RESTART flag set), the syscall will be restarted rather than
aborted.
This should be fine. It may eventually shake out
This should not contribute to load, since it¹s called out of the ptlrpcd
daemons.
On 12/18/17, 1:18 AM, "lustre-devel on behalf of NeilBrown"
wrote:
>replace l_wait_event() with wait_event_timeout() and explicit
>loop. This approach is easier to understand.
>
>Signed-off-by: NeilBrown
>---
> d
This probably shouldn¹t contribute to load, it¹s often (mostly?) run out
of the ptlrpcd daemons.
- Patrick
On 12/18/17, 1:18 AM, "lustre-devel on behalf of NeilBrown"
wrote:
>This use of l_wait_event() is a polling loop that re-checks
>every second. Make this more obvious with a while loop
>an
The lov_check_and_wait_active wait is usually (always?) going to be
asynchronous from userspace and probably shouldn¹t contribute to load.
So I guess that means schedule_timeout_idle.
On 12/18/17, 1:18 AM, "lustre-devel on behalf of NeilBrown"
wrote:
>Two places that LWI_TIMEOUT_INTERVAL() is u
Same thing as the other one, ll_statahead_thread should not contribute to
load.
IMO, mgc_process_log should not contribute to load in the case where it¹s
waiting for an import to recover, that¹s likely to be a pretty long wait
and doesn¹t really represent load. It¹s waiting for network recovery,
The wait calls in ll_statahead_thread are done in a service thread, and
should probably *not* contribute to load.
The one in osc_extent_wait is perhaps tough - It is called both from user
threads & daemon threads depending on the situation. The effect of adding
that to load average could be signi
Ah, finally we¹ve got that NOLOAD flag! This will clear up several nasty
bugs around ptrace and sigkill that come when waiting with signals blocked
in TASK_INTERRUPTIBLE. I see it was added in 2015Š The joys of working
with vendor kernels.
Thanks for these, Neil. I¹ll try to take a careful loo
Greg just recently replied to a similar patch rejecting it. I don't have his
response handy, but I bet you can find it in the archives. Briefly, this hides
possible errors rather than fixing them.
From: lustre-devel [lustre-devel-boun...@lists.lustre.org
Since it is not actually doing a printk - at least, not necessarily - I like
lustre_logmsg. lustre_output seems too vague.
- Patrick
From: HPDD-discuss [hpdd-discuss-boun...@lists.01.org] on behalf of Joe Perches
[j...@perches.com]
Sent: Friday, May 22,
Perhaps this is just a formatting error in my email client, but
shouldn't NULL be one more space over to line up with the '(' above?
On 03/18/2015 02:08 PM, p...@amd48-systeme.lip6.fr wrote:
+ rc = ll_intent_file_open(file->f_path.dentry,
+
path.dentry,
+ NULL, 0, it);
On 03/18/2015 02:31 PM, Patrick Farrell wrote:
Perhaps this is just a formatting error in my email client, but
shouldn't NULL be one more space over to line up with the '(' above?
On 03/18/2015 02:08 PM,
Ashley,
I sort of understand your larger point, but in this case, I think the purpose
of the assert is much better served by the move Rickard is suggesting.
Otherwise only one of its conditions will ever trigger. It's not that
different to die on the assertion or from a null dereference, but
Strongly agreed that execution speed is not critical here. It's the update of
a proc variable, not a tight loop or critical section.
Normally I'd leave it alone, but since you're writing a patch anyway, I'd do
'tolower' myself. I dislike the stacked case statements on a single line like
that.
Dan,
I disagree about the change suggested here. In this particular code,
'object_attr' is distinct from 'attr', as in a 'setattr' call on an inode.
'cl_object' is a distinct thing from an inode/file on disk, and specifying it
is the objects attr is helpful in understanding there is not a dir
7;ll have to be reverted.
Sorry for the trouble here!
- Patrick
From: Peng Tao [bergw...@gmail.com]
Sent: Monday, November 25, 2013 8:04 PM
To: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org; Patrick Farrell; Cheng Shao; Peng Tao;
Andreas Dilger
Subjec
20 matches
Mail list logo
