Different approaches to sync timeout: Desktop vs Mobile use cases

[tuhaowen <tuhaowen@uniontech.com>]

Hi Rafael and Linux PM maintainers,

I hope this email finds you well. I'm writing to discuss the different 
approaches that have emerged regarding sync timeout mechanisms during 
suspend/hibernation, and to seek guidance on how to proceed.

## Background

We (UnionTech) and the Google Android team (Saravana, Samuel) have been 
working on similar but fundamentally different solutions to address sync 
hangs during suspend operations. After discussions with Saravana, it has 
become clear that our approaches diverge significantly due to different 
use cases and environments.

## Our Approach - Desktop/PC Focus

Our patch: https://lore.kernel.org/all/20250909065836.32534-1-tuhaowen@uniontech.com/

**Use Case**: Desktop/laptop systems where users expect immediate feedback
**Problem**: When large file operations are in progress (e.g., copying 
files to USB drives) and users initiate suspend, ksys_sync() can hang 
indefinitely, especially when block devices are removed during the process. 
This results in:
- Black screen with no user feedback
- Users assuming the system has frozen
- Need for forced power cycles
- Poor user experience

**Solution**: Configurable sync timeout (default disabled for compatibility)
- If sync exceeds timeout, suspend fails gracefully with user feedback
- Sync continues in background after system resumes
- User can take corrective action (eject devices, etc.)
- Prevents false impression of system freeze

## Google's Approach - Mobile/Android Focus

Their patch: https://lore.kernel.org/all/CAGETcx8x5G75sQ9zVkxe+BpK7WsEk+LS6KDMd5BBR=xWPMtevg@mail.gmail.com/

**Use Case**: Mobile devices where power consumption is critical
**Problem**: Unnecessary wake-ups during sync operations
**Solution**: Abort sync only when wakeup events occur
- Wait indefinitely for sync if no wakeup sources are active
- Prioritize power efficiency over user responsiveness
- Suitable for devices where black screen is expected behavior

## Key Differences

1. **User Expectations**:
   - Desktop: Users expect responsive feedback and ability to recover
   - Mobile: Users expect device to "just work" when they next unlock

2. **Hardware Context**:
   - Desktop: Removable storage, active file operations, power adapter available
   - Mobile: Integrated storage, controlled app lifecycle, battery dependent

3. **Problem Focus**:
   - Desktop: Prevent indefinite hangs and provide user feedback
   - Mobile: Prevent unnecessary power consumption

4. **Timeout Philosophy**:
   - Desktop: Proactive timeout to maintain responsiveness
   - Mobile: Reactive abort only when wakeup events require it

## Technical Considerations

Both solutions address legitimate but different problems:

- **Desktop scenario**: User copying large files, removes USB drive, initiates 
  suspend -> ksys_sync() hangs indefinitely -> black screen -> user thinks 
  system froze

- **Mobile scenario**: Background sync during suspend -> unnecessary wake-ups 
  -> battery drain

## Request for Guidance

Given these different environments and requirements, we believe both 
approaches have merit for their respective use cases. However, we want 
to ensure we follow the kernel community's preferred approach for handling 
such divergent requirements.

Would you prefer:

1. **Unified solution**: Combine both approaches in a single patchset 
   (more complex but comprehensive)

2. **Separate solutions**: Allow both patches to coexist, targeting 
   different use cases

3. **Staged approach**: Land one solution first, then build upon it 
   (Saravana suggested this approach)

4. **Different direction**: An alternative approach we haven't considered

## Our Position

We believe the desktop use case requires proactive timeout mechanisms 
because:
- Users directly interact with the system and expect feedback
- Removable storage creates unique failure scenarios
- The cost of a failed suspend attempt is much lower than an unresponsive system
- Data integrity is preserved through background sync continuation

We're happy to collaborate on a unified solution, but we also recognize 
that desktop and mobile environments may legitimately require different 
approaches to the same underlying kernel mechanisms.

Thank you for your time and guidance on this matter. We look forward to 
your feedback on how to best serve both desktop and mobile use cases 
within the kernel's power management subsystem.

Best regards,
Haowen Tu