Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 20.12.2016 02:51, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Thursday, December 15, 2016 10:10 AM
> To: Sasikumar PC; j...@kernel.org; h...@infradead.org
> Cc: linux-scsi@vger.kernel.org; Sathya Prakash Veerichetty;
> linux-ker...@vger.kernel.org; Christopher Owens; Kiran Kumar Kasturi
> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
> based on the PCI Threshold Bandwidth
>
> On 14.12.2016 22:54, Sasikumar PC wrote:
>> Hi Tomas,
>>
>> Please see my response inline
>>
>> Thanks
>> sasi
>>
>> -Original Message-
>> From: Tomas Henzl [mailto:the...@redhat.com]
>> Sent: Friday, December 09, 2016 8:59 AM
>> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
>> Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
>> linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
>> kiran-kumar.kast...@broadcom.com
>> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast
>> path based on the PCI Threshold Bandwidth
>>
>> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>>> Large SEQ IO workload should sent as non fast path commands
>>>
>>> This patch is depending on patch 7
>>>
>>> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
>>> ---
>>>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
>> +
>>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>>>  5 files changed, 78 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>>> b/drivers/scsi/megaraid/megaraid_sas.h
>>> index 3e087ab..eb5be2b 100644
>>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>>  #define MFI_1068_FW_HANDSHAKE_OFFSET   0x64
>>>  #define MFI_1068_FW_READY  0x
>>>
>>> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
>>> +
>>>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>>> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>>> atomic_t ldio_outstanding;
>>> atomic_t fw_reset_no_pci_access;
>>>
>>> +   atomic64_t bytes_wrote; /* used for raid1 fast path enable or
>> disable */
>>> +   atomic_t r1_write_fp_capable;
>> Is a an atomic variable needed for a just boolean variable?
>> Sasi - As we need to synchronize timer thread and IO issue threads,
>> With atomic, at any point of time the value will be definitive.
>> With boolean, it depends, the value could be in transit while one
>> thread is reading and other is writing.
> This explanation is I think not good enough, as a write of a char value is
> atomic on all architectures. If you need synchronisation you probably need a
> spinlock.
> Tomash
>
> boolean may not be a char in all architectures/implementations. It could be
> implementation specific isn't it ?

On which arch? 

> Spin_Lock is heavier as the check is in IO path.

Lightest form of atomic variable for isolated write and read is probably a char 
- so why can't
you use that plain basic type to store a boolean value?

> We need it to be consistent
> non-transient value, not an exact synchronization.

Could you be please more specific - what exactly is the transient value other 
than true or false ?

> There could be more values that we may set this variable to, to make
> different decisions and value can be set in more places in future.
> Atomic will help it keep consistent and extensible.

And then you'll rename the variable and use bit operations or may use
different state values and for that a char or int which is atomic per se
are the best option.

You've tested the whole series so you try to not change anything in the series,
I'm trying to understand.
You wrote earlier here that an explicit synchronisation is not needed,
that means, that there is no race condition possible and the
code is just a bit less then ideal. ok, fine, i'll this pass.

>
> sasi
>
>>> +
>>> +
>>> struct megasas_instance_template *instancet;

RE: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Sasikumar PC]

Hi Tomas,

Please see my response inline

Thanks
sasi

-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Thursday, December 15, 2016 10:10 AM
To: Sasikumar PC; j...@kernel.org; h...@infradead.org
Cc: linux-scsi@vger.kernel.org; Sathya Prakash Veerichetty;
linux-ker...@vger.kernel.org; Christopher Owens; Kiran Kumar Kasturi
Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
based on the PCI Threshold Bandwidth

On 14.12.2016 22:54, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, December 09, 2016 8:59 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast
> path based on the PCI Threshold Bandwidth
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> Large SEQ IO workload should sent as non fast path commands
>>
>> This patch is depending on patch 7
>>
>> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
> +
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>>  5 files changed, 78 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index 3e087ab..eb5be2b 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>  #define MFI_1068_FW_HANDSHAKE_OFFSET0x64
>>  #define MFI_1068_FW_READY   0x
>>
>> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
>> +
>>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>>  atomic_t ldio_outstanding;
>>  atomic_t fw_reset_no_pci_access;
>>
>> +atomic64_t bytes_wrote; /* used for raid1 fast path enable or
> disable */
>> +atomic_t r1_write_fp_capable;
> Is a an atomic variable needed for a just boolean variable?
> Sasi - As we need to synchronize timer thread and IO issue threads,
> With atomic, at any point of time the value will be definitive.
> With boolean, it depends, the value could be in transit while one
> thread is reading and other is writing.

This explanation is I think not good enough, as a write of a char value is
atomic on all architectures. If you need synchronisation you probably need a
spinlock.
Tomash

boolean may not be a char in all architectures/implementations. It could be
implementation specific isn't it ?
Spin_Lock is heavier as the check is in IO path.We need it to be consistent
non-transient value, not an exact synchronization.
There could be more values that we may set this variable to, to make
different decisions and value can be set in more places in future.
Atomic will help it keep consistent and extensible.

sasi

>
>> +
>> +
>>  struct megasas_instance_template *instancet;
>>  struct tasklet_struct isr_tasklet;
>>  struct work_struct work_init;
>> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>>  long reset_flags;
>>  struct mutex reset_mutex;
>>  struct timer_list sriov_heartbeat_timer;
>> +struct timer_list r1_fp_hold_timer;
>>  char skip_heartbeat_timer_del;
>>  u8 requestorId;
>>  char PlasmaFW111;
>> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>>  bool is_ventura;
>>  bool msix_combined;
>>  u16 max_raid_mapsize;
>> +u64 pci_threshold_bandwidth; /* used to control the fp writes */
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 8aafb59..899d25c 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct
>> megasas_instance
> *instance)
>>  }
>>  /* Complete outstanding 

Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 14.12.2016 22:54, Sasikumar PC wrote:
> Hi Tomas,
>
> Please see my response inline
>
> Thanks
> sasi
>
> -Original Message-
> From: Tomas Henzl [mailto:the...@redhat.com]
> Sent: Friday, December 09, 2016 8:59 AM
> To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
> Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
> linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
> kiran-kumar.kast...@broadcom.com
> Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
> based on the PCI Threshold Bandwidth
>
> On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
>> Large SEQ IO workload should sent as non fast path commands
>>
>> This patch is depending on patch 7
>>
>> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
>> ---
>>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
> +
>>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>>  5 files changed, 78 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
>> b/drivers/scsi/megaraid/megaraid_sas.h
>> index 3e087ab..eb5be2b 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas.h
>> +++ b/drivers/scsi/megaraid/megaraid_sas.h
>> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>>  #define MFI_1068_FW_HANDSHAKE_OFFSET0x64
>>  #define MFI_1068_FW_READY   0x
>>
>> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
>> +
>>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>>  atomic_t ldio_outstanding;
>>  atomic_t fw_reset_no_pci_access;
>>
>> +atomic64_t bytes_wrote; /* used for raid1 fast path enable or
> disable */
>> +atomic_t r1_write_fp_capable;
> Is a an atomic variable needed for a just boolean variable?
> Sasi - As we need to synchronize timer thread and IO issue threads,
> With atomic, at any point of time the value will be definitive.
> With boolean, it depends, the value could be in transit while
> one thread is reading and other is writing.

This explanation is I think not good enough, as a write of a char value
is atomic on all architectures. If you need synchronisation you probably
need a spinlock.
tomash

>
>> +
>> +
>>  struct megasas_instance_template *instancet;
>>  struct tasklet_struct isr_tasklet;
>>  struct work_struct work_init;
>> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>>  long reset_flags;
>>  struct mutex reset_mutex;
>>  struct timer_list sriov_heartbeat_timer;
>> +struct timer_list r1_fp_hold_timer;
>>  char skip_heartbeat_timer_del;
>>  u8 requestorId;
>>  char PlasmaFW111;
>> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>>  bool is_ventura;
>>  bool msix_combined;
>>  u16 max_raid_mapsize;
>> +u64 pci_threshold_bandwidth; /* used to control the fp writes */
>>  };
>>  struct MR_LD_VF_MAP {
>>  u32 size;
>> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>> b/drivers/scsi/megaraid/megaraid_sas_base.c
>> index 8aafb59..899d25c 100644
>> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
>> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance
> *instance)
>>  }
>>  /* Complete outstanding ioctls when adapter is killed */
>>  megasas_complete_outstanding_ioctls(instance);
>> +if (instance->is_ventura)
>> +del_timer_sync(>r1_fp_hold_timer);
>> +
>>  }
>>
>>   /**
>> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned
> long instance_addr)
>>  }
>>  }
>>
>> +/*Handler for disabling/enabling raid 1 fast paths*/ void
>> +megasas_change_r1_fp_status(unsigned long instance_addr) {
>> +struct megasas_instance *instance =
>> +(struct megasas_instance *)instance_addr;
>> +if (atomic64_read(>bytes_wrote) >=
>> +instance->pci_threshold_bandwidth)
> {
>> +
>> +atomic64_set(>bytes_wrote, 0);
>> +atomic_set(>r1_wr

RE: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Sasikumar PC]

Hi Tomas,

Please see my response inline

Thanks
sasi

-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Friday, December 09, 2016 8:59 AM
To: Sasikumar Chandrasekaran; j...@kernel.org; h...@infradead.org
Cc: linux-scsi@vger.kernel.org; sathya.prak...@broadcom.com;
linux-ker...@vger.kernel.org; christopher.ow...@broadcom.com;
kiran-kumar.kast...@broadcom.com
Subject: Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path
based on the PCI Threshold Bandwidth

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar...@broadcom.com>
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48
+
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
> drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>  5 files changed, 78 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 3e087ab..eb5be2b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MFI_1068_FW_HANDSHAKE_OFFSET 0x64
>  #define MFI_1068_FW_READY0x
>
> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
> +
>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>   atomic_t ldio_outstanding;
>   atomic_t fw_reset_no_pci_access;
>
> + atomic64_t bytes_wrote; /* used for raid1 fast path enable or
disable */
> + atomic_t r1_write_fp_capable;

Is a an atomic variable needed for a just boolean variable?
Sasi - As we need to synchronize timer thread and IO issue threads,
With atomic, at any point of time the value will be definitive.
With boolean, it depends, the value could be in transit while
one thread is reading and other is writing.

> +
> +
>   struct megasas_instance_template *instancet;
>   struct tasklet_struct isr_tasklet;
>   struct work_struct work_init;
> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>   long reset_flags;
>   struct mutex reset_mutex;
>   struct timer_list sriov_heartbeat_timer;
> + struct timer_list r1_fp_hold_timer;
>   char skip_heartbeat_timer_del;
>   u8 requestorId;
>   char PlasmaFW111;
> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>   bool is_ventura;
>   bool msix_combined;
>   u16 max_raid_mapsize;
> + u64 pci_threshold_bandwidth; /* used to control the fp writes */
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 8aafb59..899d25c 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance
*instance)
>   }
>   /* Complete outstanding ioctls when adapter is killed */
>   megasas_complete_outstanding_ioctls(instance);
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>  }
>
>   /**
> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned
long instance_addr)
>   }
>  }
>
> +/*Handler for disabling/enabling raid 1 fast paths*/ void
> +megasas_change_r1_fp_status(unsigned long instance_addr) {
> + struct megasas_instance *instance =
> + (struct megasas_instance *)instance_addr;
> + if (atomic64_read(>bytes_wrote) >=
> + instance->pci_threshold_bandwidth)
{
> +
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 0);
> + } else {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + }
> + mod_timer(>r1_fp_hold_timer,
> +  jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> +}
> +
>  /**
>   * megasas_wait_for_outstanding -Wait for all outstanding cmds
>   * @instance:Adapter soft state
> @@ -5371,6 +5392,17 @@ static int megasas_init_fw(struct
megasas_instance *instance)
>   instance->skip_heartbeat_timer_del = 1;
>   }
>
> 

Re: [PATCH V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48 
> +
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>  5 files changed, 78 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 3e087ab..eb5be2b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MFI_1068_FW_HANDSHAKE_OFFSET 0x64
>  #define MFI_1068_FW_READY0x
>  
> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
> +
>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>   atomic_t ldio_outstanding;
>   atomic_t fw_reset_no_pci_access;
>  
> + atomic64_t bytes_wrote; /* used for raid1 fast path enable or disable */
> + atomic_t r1_write_fp_capable;

Is a an atomic variable needed for a just boolean variable?

> +
> +
>   struct megasas_instance_template *instancet;
>   struct tasklet_struct isr_tasklet;
>   struct work_struct work_init;
> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>   long reset_flags;
>   struct mutex reset_mutex;
>   struct timer_list sriov_heartbeat_timer;
> + struct timer_list r1_fp_hold_timer;
>   char skip_heartbeat_timer_del;
>   u8 requestorId;
>   char PlasmaFW111;
> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>   bool is_ventura;
>   bool msix_combined;
>   u16 max_raid_mapsize;
> + u64 pci_threshold_bandwidth; /* used to control the fp writes */
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 8aafb59..899d25c 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance 
> *instance)
>   }
>   /* Complete outstanding ioctls when adapter is killed */
>   megasas_complete_outstanding_ioctls(instance);
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>  }
>  
>   /**
> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned long 
> instance_addr)
>   }
>  }
>  
> +/*Handler for disabling/enabling raid 1 fast paths*/
> +void megasas_change_r1_fp_status(unsigned long instance_addr)
> +{
> + struct megasas_instance *instance =
> + (struct megasas_instance *)instance_addr;
> + if (atomic64_read(>bytes_wrote) >=
> + instance->pci_threshold_bandwidth) {
> +
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 0);
> + } else {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + }
> + mod_timer(>r1_fp_hold_timer,
> +  jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> +}
> +
>  /**
>   * megasas_wait_for_outstanding -Wait for all outstanding cmds
>   * @instance:Adapter soft state
> @@ -5371,6 +5392,17 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   instance->skip_heartbeat_timer_del = 1;
>   }
>  
> + if (instance->is_ventura) {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + megasas_start_timer(instance,
> + >r1_fp_hold_timer,
> + megasas_change_r1_fp_status,
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + dev_info(>pdev->dev, "starting the 
> raid 1 fp timer with interval %d\n",
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + }
> +
>   return 0;
>  
>  fail_get_ld_pd_list:
> @@ -6161,6 +6193,9 @@ static void megasas_shutdown_controller(struct 
> megasas_instance *instance,
>   if (instance->requestorId && !instance->skip_heartbeat_timer_del)
>   del_timer_sync(>sriov_heartbeat_timer);
>  
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>   megasas_flush_cache(instance);
>   megasas_shutdown_controller(instance, MR_DCMD_HIBERNATE_SHUTDOWN);
>  
> @@ -6280,6 +6315,16 @@