All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Apostolov <vapo@sgi.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] optimize dmapi event tests w/o dmapi config
Date: Mon, 20 Aug 2007 15:22:44 +1000	[thread overview]
Message-ID: <46C92524.7000207@sgi.com> (raw)
In-Reply-To: <46C90C77.5070502@sandeen.net>

I ran the DMAPI QA with the updated patch and it was working fine.
I will push it in the XFS development tree.
Thanks Eric.

Regards,
Vlad

Eric Sandeen wrote:
> Vlad Apostolov wrote:
>
>   
>> Eric Sandeen wrote:
>>   
>>     
>>> Defining XFS_DM_EVENT* macros to 0 in the absence of 
>>> CONFIG_XFS_DMAPI allows gcc to optimize away tests that 
>>> should never be true. Also wrap one hunk of xfs_unmount 
>>> in #ifdef CONFIG_XFS_DMAPI
>>>   
>>>     
>>>       
>> Good idea Eric. A few remarks and a question below.
>>   
>>     
>>>  
>>> +#ifdef CONFIG_XFS_DMAPI
>>>   
>>>     
>>>       
>> CONFIG_XFS_DMAPI is only defined when the DMAPI is statically linked
>> to the kernel. When DMAPI is configured as a module,  
>> CONFIG_XFS_DMAPI_MODULE
>> is defined. The HAVE_DMAPI is defined for both, static and module DMAPI
>> configurations.
>>   
>>     
> Hmm... ok.  kernel.org doesn't have that so you'll need to take care moving this 
>
> patch to the kernel.org tree I guess.
>
>   
>>>  /* Defines for determining if an event message should be sent. */
>>>  #define	DM_EVENT_ENABLED(vfsp, ip, event) ( \
>>>  	unlikely ((vfsp)->vfs_flag & VFS_DMI) && \
>>> @@ -78,6 +79,11 @@ typedef enum {
>>>  		( ((io)->io_dmevmask & (1 << event)) || \
>>>  		  ((io)->io_mount->m_dmevmask & (1 << event)) ) \
>>>  	)
>>> +#else
>>> +#define DM_EVENT_ENABLED(vfsp, ip, event) (0)
>>>   
>>>     
>>>       
>> The above should use the new two arguments DM_EVENT_ENABLED macro.
>>   
>>     
>>> +#define DM_EVENT_ENABLED_IO(vfsp, io, event) (0)
>>>   
>>>     
>>>       
>> What is this DM_EVENT_ENABLE_IO macro for?
>>   
>>     
> Ah, this is just the differernce between kernel.org & CVS I guess.
> I'm just re-defining existing macros in 2.6.22.1 to no-ops.
>
> DM_EVENT_ENABLE_IO must have been removed from CVS w/o removing from
> kernel.org (yet) - and I guess same goes for the argument count.
>
> Anyway here's a CVS patch, sorry:
>
> ------
>
> Defining XFS_DM_EVENT* macros to 0 in the absence of 
> CONFIG_XFS_DMAPI allows gcc to optimize away tests that 
> should never be true. Also wrap one hunk of xfs_unmount 
> in #ifdef CONFIG_XFS_DMAPI
>
> Stack deltas on x86, gcc 4.1:
>
> xfs_create		-16
> xfs_free_file_space	-4
> xfs_getbmap		+4
> xfs_link		-8
> xfs_mkidr		-20
> xfs_read		-24
> xfs_remove		-12
> xfs_rename		-8
> xfs_rmdir		-16
> xfs_setattr		-20
> xfs_splice_read		-20
> xfs_splice_write	-20
> xfs_unmount		-48
> xfs_write		-20
>
> Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
>
> Index: linux.orig/fs/xfs/xfs_dmapi.h
> ===================================================================
> --- linux.orig/fs/xfs/xfs_dmapi.h
> +++ linux/fs/xfs/xfs_dmapi.h
> @@ -67,11 +67,15 @@ typedef enum {
>  #define HAVE_DM_RIGHT_T
>  
>  /* Defines for determining if an event message should be sent. */
> +#ifdef HAVE_DMAPI
>  #define	DM_EVENT_ENABLED(ip, event) ( \
>  	unlikely (XFS_MTOVFS((ip)->i_mount)->vfs_flag & VFS_DMI) && \
>  		( ((ip)->i_d.di_dmevmask & (1 << event)) || \
>  		  ((ip)->i_mount->m_dmevmask & (1 << event)) ) \
>  	)
> +#else
> +#define DM_EVENT_ENABLED(ip, event)	(0)
> +#endif
>  
>  #define DM_XFS_VALID_FS_EVENTS		( \
>  	(1 << DM_EVENT_PREUNMOUNT)	| \
> Index: linux.orig/fs/xfs/xfs_vfsops.c
> ===================================================================
> --- linux.orig/fs/xfs/xfs_vfsops.c
> +++ linux/fs/xfs/xfs_vfsops.c
> @@ -572,6 +572,7 @@ xfs_unmount(
>  	rip = mp->m_rootip;
>  	rvp = XFS_ITOV(rip);
>  
> +#ifdef HAVE_DMAPI
>  	if (vfsp->vfs_flag & VFS_DMI) {
>  		error = XFS_SEND_PREUNMOUNT(mp, vfsp,
>  				rvp, DM_RIGHT_NULL, rvp, DM_RIGHT_NULL,
> @@ -584,7 +585,7 @@ xfs_unmount(
>  		unmount_event_flags = (mp->m_dmevmask & (1<<DM_EVENT_UNMOUNT))?
>  					0 : DM_FLAGS_UNWANTED;
>  	}
> -
> +#endif
>  	/*
>  	 * First blow any referenced inode from this file system
>  	 * out of the reference cache, and delete the timer.
>
>
>   

      reply	other threads:[~2007-08-20  5:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-19  6:05 [PATCH] optimize dmapi event tests w/o dmapi config Eric Sandeen
2007-08-19 19:07 ` Christoph Hellwig
2007-08-19 23:48 ` Vlad Apostolov
2007-08-20  3:37   ` Eric Sandeen
2007-08-20  5:22     ` Vlad Apostolov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46C92524.7000207@sgi.com \
    --to=vapo@sgi.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.